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1. SEGIVENTATION FUNCTIONALITY 



1.1 CURRENT OVERLAY ARCHITECTURE 

On 990/10 and 990/12 mlni-conputers , the mapping hardware allows a user 
program to be divided into three separate pieces of physical memory. These 
three pieces of physical memory are combined into one contiguous logical 
address space of up to 65,536 bytes of memory. For many applications, this 
logical address space is insufficient which led to the concept of overlays 
being developed. 

By operating system definition, one of the three segments is designated 
as the task segment, a unique one of which is required for every task. In 
addition to the task segment, one or two procedure segments can be added to 
the address space. Under DXIO, these procedure segments must precede the task 
segment but may be shared by other tasks running concurrently. Figure Figure 
1-1 below illustrates the task structure under DXIO, 
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Figure 1-1 TASK STRUCTURE OPTIONS — NO SEGMENTATION 

Under DXIO, the only escape from the address space restriction is an 
overlay. Overlays are a piece of code read from disk normally into the task 
segment and require a minimum of two disk accesses each time a new overlay is 
loaded. Since the loading of an overlay is simply the reading of a piece of a 
disk file over a portion of the task address space, the information previously 
stored at the overlay addresses is destroyed. Therefore, read/write data 
(DSEG's) must be saved external to the overlay area even if the data is only 
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required locally to the code in the overlay. 

Overlays include the facility for automatic overlay loading by linking in 
the Overlay Manager and modifying the routine entry points to point to the 
Overlay Manager. Also, a hierarchical structure (Phases) is permitted. 



1.2 GENERAL CAPABILITIES OP PROGMM SEGMENTS 

Under DNOS, procedure segments may precede the task segment as on DXIO. 
Additionally, new segments may be mapped after the task segment and theseare 
called program segments. Furthermore, these segments may be changed for other 
segments at the option of the running task by simply issuing Change Segment 
Supervisor Calls (SVC's). Although the Change Segment SVC allows changing 
procedure segments preceding thetask, most segmentation changing is done after 
the task segment so the segments can be of variable length. (Swapping in 
variable length segments before the task segment would result in the 
relocation of the task segnent with unworkable problems resulting). These 
segments need not necessarily be loaded from disk. In one case, the segments 
may be made memory resident at boot time and never loaded from disk. Also, 
the segments may remain cached in menory when not in use and then mapped in 
with zero disk accesses. In another case, an unmapped segment may not be in 
memory due to high memory requirements but can be remapped by the task in only 
one disk access. It is this characteristic of segmentation which allows the 
greatest amount of performance improvonent through reduced disk activity. 

Another feature of segments not available with overlays is the ability to 
modify DSEG's in segments, map the segnent out, then map the segment in again 
without loss of the data in the DSBG. In this fashion, large blocks of data 
can be accessed by a task without using a disk file to buffer and stage the 
data. 

The DNOS Link Editor does support linking multiple program segments in a 
single execution of the linker (one link control file), but does not support 
autanatic segment loading or a hierarchical structure for those segments. 
Multiple segments are linked by providing multiple segment corrmands in the 
link control file (see the mOS Link Editor Reference Manual , P/N 2270522-9701 
*A). Figure Figure 1-2 below illustrates the task structure under DNOS. 
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Figure 1-2 TASK STRUCTURE OPTIONS — SEGMENTATION 



1.3 SEGMENTATION: CAPABILITIES AND LIMITATIONS 

DNOS program segments are normally loaded by specific request from the 
task. Program segments mapped after the task segment are not autonatically 
loaded at task bid time but must be loaded by specific request (SVC) of the 
task. The map SVC does, however, allow all segments to be exchanged at 
runtime except the task segment (or a segment containing the Map SVC itself). 

The DNOS linker supports linking multiple procedure segments in one link 
step but only at one map position in the address space That means that the 
task structure must be TASK/SEGMENT or PROCEDURE A'ASK/SEGMENT. In terras of 
linker control comnands, there cannot be both a SEGMENT 2 and SEGMENT 3 
command in the same link control file. 

Under DXIO or DNOS, the DSBG's and CSEG's contained in procedures linked 
before the task segment are migrated to the task segment to help in 
constructing reentrant procedure segments. In a similar fashion, the CSEG's 
referenced within multiple program segments linked following the task segment 
are pronoted up to the task segment. DSEG's referenced in program segment 
links are, however, not promoted to the task segment nor reordered within the 
program segment. Therefore, if the DSEG must be in the task, it should be 
assembled separately, REP'd, and included in the task segment with an explicit 
include command. Alternately, the DSEG can be made into a CSEG which is 
promoted to the task segment (if referenced by multiple segments). The 
advantage of using a CSEG is that every label in the DSEG would have to be 
externally DEF'd and REF'd (if not included in the assembly step of the 
procedure referencing it). 
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If a program must be structured as TASK/SBGMENT/SEGMENT, multiple links 
will have to be used. Under these conditions, the actual load addresses of 
the segments would have to be specified in the link control stream on the 
SEGMENT canmand. Under these conditions, routines at the SEGMENT 2 level 
cannot reference labels defined at the SEGMENT 3 level and vice versa (and 
have those references resolved by the linker). If references are desired 
across the map locations, then a table of routine addresses could be placed in 
the task segment and subroutine calls be made indirect through that table. 

The linker does not directly support linking multiple procedure segments 
preceding the task at the same map position (ie, linking multiple procedure 
I's of Figure 1-2). Similar to linking segments at both map positions 2 and 
3, these multiple segments can be linked with multiple link steps but 
references from the task to the procedure segments (and subsequent program 
segments) cannot be resolved by the linker. 

Overlays can be linked and loaded into program segments but autanatic 
overlay loading is supported only into the task. 



1.4 CHARACTERISTICS OP SEGMENTS 

Most of the following characteristics of segments are set via the Install 
Procedure Segment (IPS) SCI cormiand or via the Modify Segment Entry (MSE) 
canmand. If a format jjnage link is used, then the MSE approach is required. 

1.4.1 Executable or Execute Protect. 

This hardware option is definable on any DNOS but functions only on the 
990/12 GPU. If execute protect is set and the Program Counter (PC) is 
transferred to the segment, a task error >A (execute protect violation) 
occurs. If the flag is not set, the segment may be executed. 

1.4.2 Read Only or ReadArite. 

This hardware option is definable on any DNOS syston but functions only 
on the 990/12 CPU. If the segment is flagged as read only (as would be set 
for code or non-modifiable data) and an attempt is made to write to the 
segment, then a task error >B (write protect violation) occurs. All segments 
containing writable DSEG's should be flagged as Read/Write. 

1.4.3 Sharable or Non-Sharable. 

This software flag indicates to the 0/S whether multiple tasks can 
simultaneously have the segment mapped into their respective address spaces. 
Most pure code segnents that can be mapped by multiple tasks (at the same 

TEXAS INSTRUMENTS INC - 4 - TIMIX 1983 



DNOS SEGMEM-ATION 06 April 1983 



logical address) would be flagged as sharable. Also, segments that contain 
data that is simultaneously needed by multiple tasks would be flagged as 
sharable. Private data for a task would not be flagged as sharable. 

1.4.4 Repli eatable. 

This software flag indicates to the 0/S whether multiple copies of a 
segment can exist at one time. Note that this flag interacts with the 
Sharable flag as follows: 1) if a segment is sharable, there would be no need 
for multiple copies; 2) if a segment is non-sharable, each task is allowed to 
use his own copy (as for routines with both code and local data) if the 
segment is replicatable; or may be excluded from having his own copy and be 
forced to wait for the one copy to becone available if the segment is non 
replicatable. 

1.4.5 Reusable or Non-Reusable. 

This software flag indicates whether a segment that is mapped out and no 
longer needed by a task (see Reserve and Exclusive below) can be used by 
another task upon a map request. If the reusable flag is set, the segment may 
be cached when not in use. If reusable is not set, the segment is discarded 
when no longer in use. 

1.4.6 Updatable. 

The updatable option is set during IPS or MSE and indicates that the 0/S 
may use ons nOmB program file as the location to swap a segtuent when that 
segment must be rolled out. This flag must be set if the Forced Write Segment 
SVC is used. This option is normally only needed for data segments whose 
contents must exist beyond the life of one task or system boot. Writing a 
sequent to the home file is equivalent to writing a large record to a Relative 
Record file (where segment installed Id corresponds to the record number). 
Note that the DNOS Supervisor Call Reference Manual describes a method for 
using Segmentation SVC's for mapping records of an unblocked relative record 
file which accomplished the same function as updatable segments. 

1.4.7 Memory Resident. 

This software flag indicates that a segment is to be loaded into memory 
when the 0/S is booted. These sequent s always remain in memory and their 
memory can never be used by other programs. This option should be used 
sparingly with performance being optained through segment caching. 

1.4.8 Memory Based Segments. 
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The above flags are defined for disk based segments. DNOS supports the 
creation of segments at task runtime via the "create onpty segment" SVC call. 
These segments are normally used for storage of data blocks. For these 
segments, there is no corresponding disk image. 

1.4.9 Modified. 

The modified option is a software flag set during mapping operations and 
indicates to the 0/S whether the outgoing segment has been modified since it 
wasmapped in. If the segment is not flagged as modified, the 0/S may discard 
the segnent when it is mapped out since a correct copy can be loaded from the 
disk in one disk access. Pure code (Write Protect) segments should not be 
flagged as modified while data segments whose data is still required should be 
flagged modified. Modified segments not mapped in are saved to the roll file 
or the home file (see Updatable below). 

1.4.10 Reserved, 

The reserve option is a software flag set via a specific mapping call and 
indicates that the segment should not be discarded regardless of the setting 
of the modified flag. Segments so marked are saved to the roll file or home 
file when not mapped in and their physical moriory is required. This flag is 
similar to the Exclusive flag except when a reserved segment is notmapped in 
to any task, any task can map the reserved segment back in. 

1.4.11 Exclusive Use. 

Exclusive use option is a software flag set via a specific mapping call 
or via aflag when a segment is mapped out (like the Modified flag). This flag 
indicates that the segment should not be discarded regardless of the setting 
of the modified flag. Segments flagged Exclusive and not mapped in can be 
mapped only by the task that marked the segment exclusive. Note that a 
segment can be flagged exclusive only once even by the same task without first 
resetting exclusive. A second exclusive map call (or mapping an exclusive 
segment out with the exclusive flag set) will result in an map SVC error >P9 
(not currently documented). 



1.5 USES OP SEGMENTS: PURE SHARED CODE 

Solving the address space restriction for procedural code can be 
accomplished by linking pure code segments (normally sharable) to be loaded in 
the second or third map position. These segments can then be shared by 
multiple copies of the same task (or by different tasks if the segment is 
loaded at the same address). To reduce segment swapping and thereby improve 
performance, collect in one segnent the routines that are normally accessed 
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together In a set. 

To access segments so linked from a high level language (COBOL, Pascal), 
include a routine that maps the desired segment then call the subroutine In 
the segment normally. The example programs illustrate this method. Note that 
for pascal, pure code is linked into the segments and the exclusive bit need 
not be set. In the COBOL example, there is a DSEG associated with each 
subroutine so the segments cannot be sharable (but can be repllcatable). 
However, since there is no local data (only LINKAGE references), the segnaents 
donot need to be reserved and can be Reusable. PI USES OP SEGMENTS: DIRTY 
PROCEDURES) The most cornnon usage for dirty procedures is for a set of 
subroutines that contain both code and data where the data stored must be 
preserved across multiple calls to the subroutines (not shown in the 
examples). This would occur in COBOL when the called subroutines contain 
WORKING-STORAGE data areas that must be maintained between calls. Since 
Pascal generates pure code subroutines, the only time this method would be 
needed for Pascal would be when assembly language DSEG's or any CSEG^s were 
Included in the segments. To reduce segment swapping and thereby improve 
performance, collect in one segnent the routines that are normally accessed 
together in a set. 

To access the segnents, write a routine (see example 3) to load the 
segments and set exclusive access (first time only). The mapping routine uses 
segment installed id's to map the segment. These installed Id's can be hard 
coded into the source program (see exanple l),or can be obtained via a CSBG 
fron a PDRMAT IMAGE link (see example 2). Once the segment is mapped in, call 
the subroutine normally (see example programs). Once the program is finished 
with the segments, a subroutine should be called to reset the Exclusive flag 
so another task could use the segments (if they are reusable). Note that if 
the task terminates, all exclusive access flags set b^^ that 
by DNOS making the segments available to other tasks. 



1.6 USES OP SEGMENTS: PRIVATE DATA 

The primary usage here is for data storage in excess of task 
addressability. Por this purpose, break up the data storage into logically 
related pieces of information which will be accessed as a set. In the case of 
Pascal, a Record structure could be defined for the various segnents, 
providing an alternative to the "NEW" function. 

1.6,1 Access to Pre-Initialized Data Segments. 

To access pre-initialized data segments, link and install the various 
segments and Install on a disk file as execute protected, non-sharable, 
read/write (and repllcatable as appropriate). Note that if pre-initialized 
data is stored in disk based segments and is modified by the task, these 
segments will not be in-memory reusable, Por non-initialized segments (or 
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where the initialized data is not modified), the segments can be installed as 
reusable. To map the segments, save installed Id's in the same methods as 
noted above for code segments. Set exclusive use on each segment once before 
mapping the segment out. Reset exclusive when finished with the segnent. 

1.6.2 Access to Memory Based Data Segments. 

To access memory based segments, provide a subroutine to create empty 
segments and save the runtime Id's (see example 3) in the task area. These 
runtime Id's are returned upon creating the segment. When creating the 
segment, set the Segment Attributes (see map SVC) for Read/Write, Execute 
Protect, and Share Protect. Also, before mapping out the segment, set 
exclusive access once. 



1.7 USES OP SEGMENTS: SHARED DATA 

Sharing data segments provides a method to pass a large block of data 
from one task to another without having to copy the data (via IPC). Access is 
via a map call using either installed Id's (disk based segments) or runtime 
Id's (memory based segments). For disk based segments, each task can store 
the installed Id's as noted above. For memory based segnents, the runtime 
Id's must be passed fran one task to another (via IPC or a dirty shared 
procedure segment). To prevent loss of segment data, one task should issue 
the reserve segment call once for all tasks using the segment. Exclusive 
should not be set because only the reserving task would then be able to access 
the segment. 

If it is desired to prevent multiple tasks accessing a shared segnent 
simultaneously, then set the non-sharable flag. Then when a task maps the 
segment and gets error >PA, the task can wait for the segment via wait on a 
semaphore (or could always wait on semaphore first then map the segment). 
When the task that is using the segment is finished with it, it will: 1) set 
the modified flag in the SVC block; 2) map out the segment; 3) post the 
samphore, waking up the next task waiting on the segment. 



1.8 NOTES ON USAGE OP SEGMENTS 



1.0.1 Keiocatabie ae^enzs. 

If the segment contains no absolute address references, different tasks 
can map the same segment at different locations. Note that this would 
normally be used only for data storage and all data items would have to be 
accessed by pointer (Pascal) or base register (Assembly). It is, however, 
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possible to write assembly language pure procedural code that is position 
independent. This code could be linked into a segment that is mapped into 
multiple tasks at different addresses (output segment on only one task link, 
DUMP^Y on all rest). Note that the address of the segment within each task 
address space is returned in the map SVC block when the segment is mapped in. 

Characteristics of position independent code include: 1) a base register 
set to point to the top of the subroutine; 2) no absolute branch instructions 
(use jumps or branch relative to subroutine base register [B (LABEL- 
START) (Rx)]; 3) all data references relative to registers. 

1.8.2 Use of IPC Within Segments. 

If the task is installed as software privileged, an IPC read or write can 
be initiated (via initiate event or setting initiate flag in I/O call block) 
and then the segment containing the buffer pointed to by the I/O call block 
mapped out. Note that neither the I/O call block nor the map SVC block can be 
in the segmentthat is to be mapped out (the map SVC and I/O SVC blocks would 
normally reside in the task segnent). 

Thus a server task can operate on multiple IPC channels with each channel 
or requestor using a unique segnent per channel. This task need only wait for 
any I/O completion, then scan all the I/O SVC blocks to see which I/O 
completed. Then that segnent can be mapped in and the request processed. The 
segnent associated with the IPC channel could contain local data particular to 
the requestor that is to be saved across multiple requests. 

X.U.J KJUlrCULLLLli^ OC^HCllU JLllOUCLXXCU XU D . 

There are three options for making installed segment Ids available to the 
source program: 1) define segment Id in link control source and use FORMAT 
IMAGE link; 2) let linker assign segment Id's with FORMAT IMAGE link; and 3) 
define segment Id's at IPS time with FORMAT ASCII links. 

Case 1: When the segment Id's are defined within the link stream, these 
same Id's can be hard coded into the source program (example 1). However, the 
Id's can also be obtained by REP'ing the segment name in a common area (see 
below). 

Case 2: When the linker assigns the segiient Id's, the source program 
needs to access the installed Id's via REP'ing the segment name of the link as 
shown below (example 2). 
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SEGMENT 2, SEGl 
INCLUDE . . . 



SEGMENT 2, SEG2 



CSEG 'SEGTBL' 
DEP SEGTBL 

REP SEGl , SBG2 , SEG3 , SEG4 , SEG5 
SEGTBL DATA SEG1,SEG2,SEG3,SEG4,SEG5 
CEND 

Case 3: When segment Id's are set during IPS, the source program must 
have the installed segment Id's hard coded (into a table or within load 
subroutine call). 



1.9 THE SEGMENT MANAGEMENT SVC 
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1.10 NOTES ON USING Tfffi SEGMENT MANAGEMENT SVC 



* Segment address is set after most segmentation SVC'S. This address 
can be used for accessing data segments as a base register of Pascal 
pointer. Thus the program need not have defined this load address 
within the code. 

* Map installed segments by setting the position flag and setting the 
map location (1, 2 or 3) in the position bits. 

* Segments can be replaced either by specifying the outgoing segment's 
position or runtime Id. The O/S sets the runtime id of the segment 
when it is map in so this runtime segment can be used to reference 
segments if desired. If both disk and memory based segments were 
being mapped by the same SVC block, it might be easier to use runtime 
Id rather than installed id. 

* Tasks should release all segments no longer in use (reset exclusive 
or unreserve). The O/S will reset exclusive on all segnents reserved 
by a task when that task terminates. 



WARNING 

IP A SEGMENT IS CACHABLE (LUNO ASSIGNED TO PROGRAM FILE 
AND "IN MEMORY REUSABLE" SET) AND A NEW COPY IS LINKED, AN 
EXECUTING PROGRAM MAY GET THE OLD COPY. ONLY BY IPL CAN 
THE NEW COPY BE GUARANTEED TO BE LOADED. 
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2. SAMPLE PROGRAI^ 

Pour sample programs have been Included to illustrate most of the 
principles discussed above. Three of these programs are Pascal as Pascal is 
the most difficult to use with segmentation. Some assembly language routines 
are included which are used to access the segment Id»s or to map the segments. 

For Pascal, there is a particular problem with using segments. That is 
the usage by the runtime of Get Memory S7C calls when the program issues NEW 
calls. As the size of the task segment cannot change (so segments will always 
map at the same location), the Get Memory SVC calls must be bypassed. As all 
the Get Memory calls are issued by a library routine called GET$ME, a special 
version of this routine is provided that allocates memory f ran a fixed common 
area (called STKHEP). V/hen this fixed space is exhausted the standard 
overflow messages will be issued. GEr$ME is the first module in the listings. 
Note also for Pascal that a confnion runtime was linked and used. 

2.10.1 Example 1: Pascal, Pure Code Segments, Hard Coded SegTient Id^s. 

Included in the listings is the Pascal source program, the link control 
file, and the output results. The source program illustrates the Map SVC 
record definitions and the mapping of the segments by installed Id's. Pay 
careful attention to the flag settings used by the routine. The^CHANGESEG and 
INITSVC routines are used in conjunction with each other. That is, INITSVC is 
designed to use with mapping segments by installed Id. In the link control, 
segment Id's 2 and 3 are used for the segnents and these Id's are set up in 
the first two lines of the main program. 

2.10.2 Example 2: Pascal, Pure Code Segments, Segment Id's from Link. 

The first listing for example 2 is an assembly language common called 
"SEGTBL" that will pick up the segment Id's fran the link step. This common 
is designed to be used in conjunction with the CHANGESEG routine used in 
example 2 in that the procedure name is passed to CHANGESEG and CHANGESEG 
accesses SEGTBL to obtain an associated segment Id. Note that CHANGESEG does 
not issue the map SVC if the segment is already mapped in. In this fashion, 
the location of subroutines within the segments need not be known within the 
Pascal source. The link control and results are almost exactly the same as 
for example 1. 

2.10.3 Example 3: Pascal, Private Data Segnents, Runtime Segment Id's. 

This example illustrates use of segments for stored private data. The 
method is to create an empty segment, move 100 integers into the segment, then 
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repeat this process three more times. Then each of the segnents Is mapped 
back In and the contents of the segments verified. Here the INITSVC routine 
Is tailored for mapping segments by runtime Id and the map routine Is called 
SWITCHSEG since It Is radically different from either of the CHANGESEG 
routines of examples 1 and 2. Again note the use of the map SVC flags. The 
link control does not Include any segments since these all segments referenced 
are created at runtime. The listings Include the Pascal source, the link 
control, and the results of the program run. 

2.10.4 Example 4: COBOL, Dirty Code Segments, Segment Id's from Link. 

This Is an example of a COBOL program that will map In pieces of dirty 
code (dirty since COBOL subroutine contains 48 byte DSEG used for workspace 
and temporary data). The assembly language common "SBGTBL" Is used to access 
the Installed segment Id's and a COBOL callable assembly language map 
subroutine "MAPSEG" accesses SEGTBL, maps the segments, and sets exclusive 
use. The MAPSEG subroutine Is the first listing of example followed by the 
COBOL main followed by the called COBOL subroutines. The link control Is 
similar to examples 1 and 2 except a COBOL runtime Is used. 



TEXAS INSTRUMENTS INC - 13 - TIMIX 1983 



GET$ME 
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0001 

0002 0000 

0003 
0004 

0005 
0006 
0007 
0008 

0009 
0010 
0011 
0012 
0013 
0014 

0015 
0016 

0017 
0018 
0019 
0020 
0021 
0022 
0023 
0024 
0025 

0026 0000 

0027 0008 
OOOA 

0028 

0029 OOOC 

0030 OOOE 
0010 

0031 0012 

0032 0014 
0016 

0033 0018 

0034 OOIA 
OOIC 

0035 OOIE 
0020 

0036 0022 

0037 0024 
0026 

0038 0028 

0039 002A 
002C 

0040 002E 
0030 

0041 0032 
0034 

0042 0036 

0043 0038 

0044 003A 

0045 0000 

0046 0000 

0047 0002 
0048 
0049 3002 

NO ERRORS. 



0024 
0028 
002A 

47 
0038' 
0000' 

02A9 

04E9 

0024 

04C8 

C069 

0028 

0581 

0241 

PPPE 

A060 

0000+ 

1807 

0281 

3002+ 

1B04 

C220 



SZ' ROUNDED 



IDT 'GET$ME' 
PSEG 
« PROCEDURE GET$MEM(SZ: INTEGER; VAR PTR:MEMPTR) 

« . — ■ 

* PURPOSE: 
» SIMULATES GET MEMORY SERVICE CALL TO GET ADDITIONAL 

MEMORY BY ALLOCATING A FIXED STATIC BLOCK. THE REGION 

IS NOT CLEARED BY THE CODE. 

» INPUTS: 

SZ: SIZE (IN BYTES) OF THE REGION DESIRED. 

PROCEDURES CALLED: NONE. 

* OUTPUTS: 

* PTR: POINTER TO A NEW MEMORY REGION OP SIZE 

* UP TO AN EVEN NUMBER. 

* FXCFPTIONS * 

» IP THE REGION COULD NOT BE OBTAINED, PTR=NIL IS RETURNED 

* HISTORY: 01/10/83: ORIGINAL. 

* NOTE- LINK WITH INCLUDE FOR P$MAIN VICE MAIN FOR FIRST 

* MODULE IN LINK AS GET$MEM IS IN MAIN PARTIAL LINK. 
$ „^_._.____^ — — . ,__— — — _.— _— — «.„__-.—————— — — — — 

» 

RTNADR EQU 
ARGl EQU 
ARG2 EQU 

* PROCEDURE 
PROLOG TEXT 

DATA 

DEP 
GET$ME STWP 
CLR 

CLR 
MOV 

INC 
ANDI 



36 
40 

42 

GET$MEM(SZ: INTEGER; VAR PTR:MEMPTR); 

'GET$MEM ' 
EPILOG, PROLOG 

GET$ME 

R9 
@RTNADR(R9) 

R8 
@ARG1(R9),R1 

Rl 
R1,>FFPE 



GET ADDRESS CURRENT WORKSPACE 
FLAG SHORT LINKAGE TO DEBUGGER 

SET NIL RETURN IN CASE ERROR 
GET DESIRED SIZE 

ROUND UP TO EVEN 



A @B$NEXT,R1 

JOC EXIT 

CI R1,B$END 

JH EXIT 

MOV @B$NEXT , R8 



MOV R1,@B$NEXT 



0000+ 

C801 

0000+ 

C0A9 EXIT MOV @ARG2(R9),R2 

002A 

C488 MOV R8,»R2 

0380 EPILOG RTWP 

PEND 

CSEG 'STKHEP' 
0002+ B$NEXT DATA $+2 

BSS >3000 
3002+ B$END EQU $ 

CEND 
NO WARNINGS 



GET ADDRESS LAST REQ BYTE 

PUNT ON ADDRESS WRAP 
PAST END OF BLOCK? 

YES, PUNT 



UPDATE NEXT FREE AREA 

GET ADDRESS OP RETURNED PTR 

RETURN ADDRESS OP BLOCK 
TO CALLER 



ADDRESS NEXT FREE WORD 
FIXED MEMORY AVAILABLE BLOCK 
END OP THE MEMORY BLOCK 



DXPSCL 
MAINl 

PROGRAM MAINl; 
(* 

(* 
(* 
(* 
(* 
(* 
(* 
(» 
(* 
(* 
(* 
(* 
(» 
(* 
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THIS PROGRAM ILLUSTRATES THE USE OP DNOS SEGMENTATION TO 
MAP IN PIECES OP PURE PASCAL CODE AND THEN EXECUTING THEM. 
NOTE THAT IP MULTIPLE COPIES OP THIS PROGRAM WERE BEING 
EXECUTED, THEN THE SEGMENTS COULD BE INSTALLED AS SHARABLE. 
ALSO, SINCE THERE IS NO WRITABLE DATA IN THE SEGMENTS, 
THERE IS NO NEED TO SET RESERVE OR SET EXCLUSIVE ACCESS. 
THE LOAD ADDRESS OP THE SEGMENTS IS DETERMINED BY THE LINK 
EDITOR AS IS THE ADDRESS OP PROCl, PR0C2, PR0C3, AND PR0C4. ») 
THE ID'S OP THE SEGMENTS IS PIXED IN THE LINK CONTROL PILE *) 
AND SET WITHIN THE PROCEDURE SECTION OP THE MAIN ROUTINE. 



THE MAP SVC BLOCK AND THE CONSTANTS WERE SET UP AS COPY 
PILES SO THEY COULD BE USED POR OTHER EXAMPLES. 



*) 
») 
*) 
*) 
*) 
*) 
*) 
*) 



*) 
*) 
*) 
*) 



CONST 
(*— _. 

(* 



■*) 
*) 



COMMONLY USED CONSTANT DEPINITIONS 



MAP_SVC_CODE = #40; 

CODE_SEG_POS = 3; 

MAP_PLAGS_POSIT = #C0 

MAP_FLAGS RESREL = #40 

OWN_TASK_EUNO = #PP 

MAP SVC SUB OP-CODES: 

CHANGE_SEG = #00 

CREATE_SEG = #01 

RESERVE_SEG = #02 

RELEASE_SEG = #03 

GET_SEG_STATUS = #04 

PORCE_WRITE = #05 

LOAD_SEG = #09 

UNLOAD_SEG = #0A 

SET_EXCLUSIVE = #0B 

RESET EXCLUSIVE = #0C; 



* SVC CODE POR MAP «) 

» MAP POSITION POR NEW SEGMENTS *) 

* MAP PLAGS: MAP BY POSIT / LUNO *) 

* MAP PLAGS POR RESERVE/RELEASE *) 

* LUNO POR OWN PROGRAM PILE *) 



CHANGE SEGMENT *) 
CREATE SEGMENT *) 
RESERVE SEGMENT *) 
RELEASE SEGMENT *) 
GET SEGMENT STATUS *) 
PORCE WRITE SEG. «) 

* MAKE SEG. MEMORY RESIDENT *) 

* RELEASE MEMORY RESIDENT SEG. 
» SET EXCLUSIVE USE OP SEG. *) 

* RESET EXCLUSIVE USE *) 



TYPE 
(* 



■») 

*) 

■*) 



COMMONLY USED TYPE DEPINITIONS 



BYTE 
NAME 

SEGTBL_ENTRY 
PROC_NAME 
SEG_ID 
END; 



= . . 255 • 

= PACKED 'array [1..6] OP CHAR; 

= PACKED RECORD; 
: NAME; 
: INTEGER; 
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(*$ PAGE 

(* 

(* 

(* 



*) 



DNOS 990 SEGMENTATION SVC FIELD DEFINITIONS 



■*) 

*) 

•*) 



T_MAPSVC 

SVC_CODE 

ERR_CODE 

OP CODE 

MA7_LUN0 

MAP_FLAG 

MAP_POS 

FILLl 

NEW_SEGID 

OLD_SEGID 

SEG_ADDR 

SEG_SIZE 

SEG ATTRIB 

FILr2 
END; " T MAPSVC " 



PACKED RECORD; 




BYTE; 


(* 


BYTE; 


(* 


BYTE; 


(* 


BYTE; 


(* 


BYTE; 


(* 


BYTE; 


(* 


INTEGER; 


(* 


INTEGER; 


(* 


INTEGER; 


(* 


INTEGER; 


(* 


INTEGER; 


(* 


INTEGER; 


(* 


INTEGER; 


(* 



SVC CODE = >40 *) 
RETURNED ERROR CODE *) 
MAP OP CODE *) 
LUNO OF PROG FILE *) 
FLAGS *) 

MAP POSITION (0,1,2) *) 
FIRST WORD NEW SEG ID *) 
NEW SEGMENT *) 
OLD SEGMENT *) 
RETURNED ADDR OF SEG *) 
SIZE OF SEGMENT (I/O) ») 
SEGMENT ATTRIBUTES *) 
RESERVED *) 



VAR 

SEG1_ID 
SEG2 ID 



INTEGER; 
INTEGER; 



(* SEGMENT ID OF SEGMENT 1 *) 
(* SEGMENT ID OF SEGMENT 2 ») 



COMMON 
MAPSVC 
MAP_SVCB 
END; " 



RECORD 
T MAPSVC; 



PROCEDURE SVC$(SVC BLOCK : INTEGER); EXTERNAL; 



DXPSCL 
INITSVC 
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(*$ PAGE *) 

PROCEDURE INITSVC; 
(* _ ,_ 

(* 
(* 



THIS ROUTINE INITIALIZED THE MAP SVC BLOCK AS INDICATED 
IN THE COMMENTS BELOW. 



ACCESS MAPSVC; 

BEGIN " PROCEDURE INITSVC 
WITH MAPSVC, MAP_SVCB DO 

BEGIN " INITIALIZE MAP SVC BLOCK 
SVC_CODE 
MAP_LUNO 
MAP_FLAG 
MAP_POS 
PILLl := 0; 
OLD_SEGID := 0; 
END; " INITIALIZE MAP SVC BLOCK 
END; " PROCEDURE INITSVC 



= MAP_SVC_CODE; 
= OWN_TASK_LUNO; 
= MAP_FLAGS_POSIT; 
= CODE SEG POS; 



.*) 

*) 
*) 



(» SET SVC CODE *) 

(* SEGMENTS PROM OWN PROG PILE «) 

(* MAP BY POSITION AND LUNO *) 

(» LOCATION TO MAP SEGMENTS ») 

(* PIRST WORD NEW SEG TO ZERO *) 

(* INITIAL OUTGOING SEG TO ZERO *) 



PROCEDURE CHANGESEG(VAR SEG ID : INTEGER); 

(» Z 

(* THIS ROUTINE ISSUES THE MAP SVC SUPERVISOR CALL AFTER 

(* SETTING THE NEW SEGMENT ID AND TYPE OF MAP SVC (OP CODE) 

(* SOME ERROR PROCESSING IS ILLUSTRATED BUT WOULD MOST LIKELY 

(* BE INSU^'^i'ICIeNt bVH MOST PROGRAMS. 

(* 



■*) 
*) 
*) 
*) 
*) 
■*) 



ACCESS MAPSVC; 

BEGIN " PROCEDURE CHANGESEG 
WITH MAPSVC, MAP_SVCB DO 

BEGIN " INITIALIZE MAP SVC BLOCK 
OP_CODE := CHANGE_SEG; 
NEW SEGID := SEG_ID; 
SVCf(LOCATION(MAP SVCB)); 
IP (ERR_CODE <> OT THEN 
BEGIN " PUNT ON SVC ERROR 

WRITELNC ERROR IN MAPPING SEGMENT; SEG ID = 'SEG ID-2 

' ERROR CODE = ' ,ERR_CODE: 4 ).; 
ESCAPE MAINl; 
END; " PUNT ON SVC ERROR 



(* SET FOR CHANGE SEG *) 
(* SET INSTALLED ID *) 
(* MAP IN SEGMENT *) 



END; " INITIALIZE MAP SVC BLOCK 
END; " PROCEDURE CHANGESEG 
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(»$ PAGE *) 

(* -^ — *) 

(* THESE PROCEDURES WILL BE CALLED ONE AT A TIME PROM THE ») 
(* MAIN ROUTINE. EACH WILL PRINT ONE LINE TO STANDARD OUTPUT. *) 
(» • *) 

PROCEDURE PROCl; 

BEGIN " PROCEDURE PROCl 

WRITELNC THIS LINE WRITTEN PROM PROCEDURE 1'); 
END; " PROCEDURE PROCl 

PROCEDURE PR0C2; 

BEGIN " PROCEDURE PR0C2 

WRITELNC THIS LINE WRITTEN PROM PROCEDURE 2'); 
END; " PROCEDURE PR0C2 

PROCEDURE PR0C3; 

BEGIN " PROCEDURE PR0C3 

WRITELNC THIS LINE WRITTEN PROM PROCEDURE 3'); 
END; " PROCEDURE PR0C3 

PROCEDURE PR0C4; 

BEGIN " PROCEDURE PR0C4 

WRITELNC THIS LINE WRITTEN PROM PROCEDURE 4'); 
END; " PROCEDURE PR0C4 



(» *) 

(* MAIN ROUTINE. SETS SEGMENT ID VARIABLES THEN CALLS OTHER ») 
(* SUBROUTINES. *) 

(* *) 

BEGIN 

SEGl ID := 2; (* ID'S OP SEGMENTS SET WITHIN ») 

SEG2~ID := 3; (* CODE HERE AND ON LINK PILE. *) 

INITSVC; (* INITIALIZE MAP SVC *) 

REWRITE (OUTPUT); (* OPEN OUTPUT, WRITE PIRST MSG *) 

WRITELNC THIS LINE WRITTEN PROM MAIN'); 

CHANGESEG(SEG1 ID); (* MAP IN PROCl AND PR0C2 *) 

PROCl; ~ (* CALL PROCl *) 

PR0C2; (* CALL PR0C2 *) 

CHANGESEG(SEG2 ID); ( * MAP IN PR0C3 AND PR0C4 ») 

PR0C4; (* CALL PR0C4 *) 

END. 



LIBRARY 

LIBRARY 

PARTIAL 

PHASE 0, 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

INCLUDE 

END 



<<<<<<<< 

K.TIMIX.O 
.TIP.OBJ 

RUNTIME 

DSTR$$ 

G0$ 

MM$DIR 

TERiyi$ 

PL$INI 

WRS$T 

CLS$ 

DSTRY$ 

INIT$ 

RSUMR$ 

MSG$ 

ENS$T 

DMPP$H 

CLOSE$ 

CUR$ 

SCB$IN 

REWND$ 

IO$ERR 

PUT$RC 

PREE$ 

GET$PA 

HEAP$T 

CREAT$ 

P$INIT 

WRX$T 

DUMP$S 

DIV$ 

OPN$PI 

lr'M$TlO 

STK$MA 

PUTCH$ 

CMP$ST 

S$NAME 



COMMON TIP RUNTIME PROCEDURES LINK CONTROL >>>>>>>> 



INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 



(ENT$ 

(MESAG$ 

(P$TERM 

(MOV$N 

(REWRT$ 

(WRLN$ 

(ABEND$ 

(ENT$MD' 

(RESUM$ 

(SCIRTNS) 

(ENX$T 

(DUMP$P 

(PB$INI 

(ENI$T 

(P$$TRM' 

(OPEN$ 

(WREOP$ 

(TX$ERR 

(scb$pr; 

(TIP$TC 

(SVC$ 

(NEW$ 

(INIT$1 

(STACK$ 

(PRT$ME 

(CLS$PI 

(SET$NA 

(PM$IO 

(GET$ME 

(EOLN$ 

(WRC$T 

(WRI$T 

(MAP$ 



<<< MAIN 1 LINK CONTROL >>> 

FORMAT IMAGE, REPLACE 
LIBRARY K.TIMIX.O 
LIBRARY .TIP.OBJ 
PROCEDURE RUNTIM 
INCLUDE (RUNTIM) 
PHASED, MAINl 
INCLUDE (P$MAIN) 
ALLOCATE 
INCLUDE (MAINl) 
SEGMENT 3,SEG1,ID 2 
INCLUDE (PROCl) 
INCLUDE (PR0C2) 
SEGMENT 3,SEG2,ID 3 
INCLUDE (PR0C3; 
INCLUDE (PR0C4) 
END 



<<< RESULTS OP MAINl RUN >>> 

THIS LINE WRITEN PROM MAIN 
THIS LINE WRITEN PROM PROCEDURE 1 
THIS LINE WRITEN PROM PROCEDURE 2 
THIS LINE WRITEN PROM PROCEDURE 3 
THIS LINE WRITEN FROM PROCEDURE 4 



SEGTBL 
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0001 

0002 0000 
0003 
0004 
0005 
0006 
0007 
0008 . 

0009 
0010 
0011 
0012 

0013 
0014 

0015 
0016 
0017 
0018 
0019 
0020 

0021 0000 

0022 0000 
0023 
0024 

0025 0002 

0026 0008 

0027 OOOA 

0028 0010 

0029 
0030 

0031 0012 

0032 0018 

0033 OOIA 

0034 0020 

0035 0022 
0036 
0037 0022 

NO ERRORS, 



0004 



50 
0000 

50 
0008 + 



50 
0000 

50 
0018+ 



IDT 'SEGTBL' 
CSEG 'SEGTBL' 

THIS MODULE CONTAINS A TABLE OP SUBROUTINE NAMES AND 
THEIR ASSOCIATED SEGMENT ID'S. THE SEGMENT ID'S ARE 
OBTAINED PROM THE PORMAT IMAGE LINK BY SPECIPYING 
THE SEGMENT NAME ON THE DATA STATEMENT. NOTE THAT 
THIS TABLE AND THE LINK CONTROL STREAM MUST BE KEPT 
IN SYNC MANUALLY BY EDITING BOTH PILES AS MODULES 
ARE ADDED TO A PARTICULAR SEGMENT OR AS SEGMENTS ARE 
ADDED. 

EACH TABLE ENTRY IS THE SIX CHARACTER TEXT NAME OP 
THE MODULE FOLLOWED BY A ONE WORD INTEGER SEGMENT 
ID. THE FIRST WORD IN THE TABLE IS THE NUMBER OF 
ENTRIES IN THE TABLE. 

ALL SEGMENT NAMES MUST BE EXTERNALLY REFERENCED: 



REP SEG1,SEG2 
DATA (TBLEND-$-2)/8 



TEXT 'PROCl ' 
DATA SEGl 
TEXT 'PR0C2 ' 
DATA SEGl 



TEXT 'PR0C3 ' 
DATA SEG2 
TEXT 'PR0C4 ' 
DATA SEG2 



0022+ TBLEND EQU $ 
CEND 
NO WARNINGS 



NUMBER OP TABLE ENTRIES 

PROCEDURES IN SEGMENT 1 
ROUTINE NAME 
PHASE NAME FOR SEGMENT 
ROUTINE NAME 
PHASE NAME FOR SEGMENT 

PROCEDURES IN SEGMENT 2 
ROUTINE NAME 
PHASE NAME FOR SEGMENT 
ROUTINE NAME 
PHASE NAME FOR SEGMENT 

END OP TABLE 
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PROGRAM MAIN2; 

(* >— .^,_^_. ^^„_ ») 

THIS PROGRAM ILLUSTRATES THE USE OP DNOS SEGMENTATION TO *) 

MAP IN PIECES OF PURE PASCAL CODE AND THEN EXECUTING THEM. *) 

NOTE THAT IP MULTIPLE COPIES OP THIS PROGRAM WERE BEING «) 

EXECUTED, THEN THE SEGMENTS COULD BE INSTALLED AS SHARABLE. *) 

ALSO, SINCE THERE IS NO WRITABLE DATA IN THE SEGMENTS, *) 

THERE IS NO NEED TO SET RESERVE OR SET EXCLUSIVE ACCESS. *) 

THE LOAD ADDRESS OP THE SEGMENTS IS DETERMINED BY THE LINK *) 

EDITOR AS IS THE ADDRESS OP PROCl, PR0C2, PR0C3, AND PR0C4. *) 

THE ID'S OP THE SEGMENTS IS PIXED IN THE LINK CONTROL PILE ») 
AND DETERMINED PROM THE LINK STREAM DYNAMICALLY. 



(* 
(* 
(* 
(* 
(* 
(* 
(* 
(* 
(* 
(* 
(* 
(* 
(* 



THE MAP SVC BLOCK AND THE CONSTANTS WERE SET UP AS COPY 
PILES SO THEY COULD BE USED POR OTHER EXAMPLES. 



*) 
*) 
*) 
*) 



CONST 
(* 



■*) 

*) 

■*) 



COMMONLY USED CONSTANT DEFINITIONS 



MAP_SVC_CODE = #40; 

CODE_SEG_POS = 3; 

MAP_PLAGS_POSIT = #C0; 

MAP_PLAGS RESREL = #40; 

OWN_TASK_LUNO = #PP; 

M A "D <:}\rn OTtn r\Ti r^rwsr^rt . 
1'j.rvi. uvv OUI3 ^r—Kj^UEjO'. 

CHANGE_SEG = #00 

CREATE_SEG = #01 

RESERVE_SEG = #02 

RELEASE_SEG = #03 

GET_SEG_STATUS = #04 

PORCE_WRITE = #05 

LOAD_SEG = #09 

UNLOAD_SEG = #0A 

SET_EXCLUSIVE = #0B 

RESET_EXCLUSIVE = #00; 



* SVC CODE POR MAP *) 

* MAP POSITION POR NEW SEGMENTS *) 

* MAP PLAGS: MAP BY POSIT / LUNO *) 

* MAP PLAGS POR RESERVE/RELEASE *) 

* LUNO POR OWN PROGRAM PILE *) 



CHANGE SEGMENT *) 
CREATE SEGMENT *) 
RESERVE SEGMENT *) 
RELEASE SEGMENT *) 
GET SEGMENT STATUS *) 
PORCE WRITE SEG. *) 

* MAKE SEG. MEMORY RESIDENT «) 
» RELEASE MEMORY RESIDENT SEG. 

* SET EXCLUSIVE USE OP SEG. ») 
» RESET EXCLUSIVE USE *) 



*) 



TYPE 
(* 



*) 
■*) 



COMMONLY USED TYPE DEFINITIONS 



BYTE 
NAME 

SEGTBL_ENTRY 
PROC_NAME 
SEG_ID 
END; 



= 0..255; 

= PACKED ARRAY ri..6] OP CHAR; 

= PACKED RECORD; 
: NAME; 
: INTEGER; 
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1.7,0 81.212 TI 990 PASCAL COMPILER 



02/11/83 10:43:01 
PAGE 2 



DNOS 990 SEGMENTATION SVC FIELD DEFINITIONS 



*) 
■*) 



T_MAPSVC 

SVC_CODE 

ERR_CODE 

OP_CODE 

MAP_LUNO 

MAP_PLAG 

MAP POS 

FILLl 

NEW_SEGID 

OLD_SEGID 

SEG_ADDR 

SEG_SIZE 

SEG_ATTRIB 

FILL2 
END; " T_MAPSVC " 

VAR 

SEG1_ID 
SEG2_ID 
ROUTINE_NAME 

COMMON 
MAPSVC 

MAP_SVCB 

END; 
SEGTBL 

NUM_ENTRIES 

SEGLIST 

END; 



PACKED RECORD; 

BYTE; 

BYTE; 

BYTE; 

BYTE; 

BYTE; 

BYTE; 

INTEGER; 

INTEGER 

INTEGER 

INTEGER 

INTEGER 

INTEGER 

INTEGER 



INTEGER; 
INTEGER; 
NAME; 



« SVC CODE = >40 *) 

» RETURNED ERROR CODE *) 

* MAP OP CODE *) 

* LUNO OF' PROG PILE *) 

* FLAGS *) 

* MAP POSITION (0,1,2) *) 

» FIRST WORD NEW SEG ID *) 
» NEW SEGMENT *) 
« OLD SEGMENT *) 

* RETURNED ADDR OF SEG *) 

* SIZE OP SEGMENT (I/O) *) 
« SEGMENT ATTRIBUTES «) 

« RESERVED *) 



(* SEGMENT ID OF SEGMENT 1 *) 
(* SEGMENT ID OF SEGMENT 2 *) 



: RECORD 
: T_MAPSVC; 

RECORD 

INTEGER; 

ARRAY [1..10] OF SEGTBL ENTRY; 



PROCEDURE SVC$(SVC BLOCK : INTEGER); EXTERNAL; 



PROCEDURE INITSVC; 

(» 

(» THIS ROUTINE INITIALIZED THE MAP SVC BLOCK AS INDICATED 

(» IN THE COMMENTS BELOW. 

(* — — - 

ACCESS MAPSVC; 



■*) 
*) 
*) 
■») 



BEGIN " PROCEDURE INITSVC 
WITH MAPSVC, MAP_SVCB DO 

BEGIN " INITIALIZE MAP SVC BLOCK 



= MAP_SVC_CODE; 
= OWN_TASK_LUNO; 
= MAP_FLAGS_POSIT; 
= CODE SEG POS; 



SVC_CODE 
MAP_LUNO 
MAP_PLAG 
MAP_POS 
FILLl := 0; 
OLD_SEGID := 0; 
END; " INITIALIZE MAP SVC BLOCK 
END; " PROCEDURE INITSVC 



(* SET SVC CODE ») 

(* SEGMENTS FROM OWN PROG PILE *) 

(* MAP BY POSITION AND LUNO *) 

(» LOCATION TO MAP SEGMENTS *) 

(» FIRST WORD NEW SEG TO ZERO *) 

(* INITIAL OUTGOING SEG TO ZERO ») 
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(*$ PAGE *) 

PROCEDURE CHANGESEG(VAR ROUTINE_NAME : NAME); 

(» ») 

(* THIS ROUTINE TAKES THE ROUTINE NAME AND MAPS IT TO A *) 

(* ID THROUGH THE COMMON SEGTBL. THEN IP THAT SEGMENT IS NOT ») 

(* MAPPED IN, IT IS MAPPED IN VIA A MAP SVC SUPERVISOR CALL. ») 

(* THE NEW SEGMENT ID AND TYPE OP MAP SVC (OP_CODE) ARE SET. *) 

(» SOME ERROR PROCESSING IS ILLUSTRATED BUT WOULD MOST LIKELY ») 

(* BE INSUFFICIENT FOR MOST PROGRAMS. «) 

(* , „ *) 

VAR 

PROC_SEGID : INTEGER; 

ACCESS MAPSVC, SEGTBL; 

BEGIN " PROCEDURE CHANGESEG 

WITH MAPSVC, MAP_SVCB, SEGTBL DO 
BEGIN " MAP SEGMENT IF REQUIRED 

PROC_SEGID := 0; (* ASSUME SEGMENT NOT FOUND *) 

FOR I := 1 TO NUM_ENTRIES DO 

IP SEGLIST[I].PROC_NAME = ROUTINE_NAME THEN 
PROC_SEGID := SEGLIST[I] .SEG ID; 
IF PROC_SEGID = THEN 

BEGIN " PUNT ON BAD PROC NAME 

WRITELNC INVALID PROCEDURE NAME; NAME = ', ROUTINE NAME); 
ESCAPE MAIN2; 
END; " PUNT ON BAD PROC NAME 

IP NEW_SEGID = PROC_SEGID THEN 
ESCAPE CHANGESEG; 

OP_CODE := CHANGE_SEG; (» SET FOR CHANGE SEG *) 
NEW SEGID := PROC_SEGID; (» SET INSTALLED ID *) 
SVCf( LOCATION (MAP SVCB)); (» MAP IN SEGMENT *) 
IP (ERR_CODE <> OT THEN 
BEGIN " PUNT ON SVC ERROR 

WRITELNC ERROR IN MAPPING SEGMENT; SEG ID = ' , 

NEW_SEGID:2, ' ERROR CODE = ' ,ERR CODE: 4); 
ESCAPE MAIN2; 
END; " PUNT ON SVC ERROR 

END; " MAP SEGMENT IF REQUIRED 
END; " PROCEDURE CHANGESEG 
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(*$ PAGE *) 

(« . , . — . — . ' ■ *) 

(« THESE PROCEDURES WILL BE CALLED ONE AT A TIME PROM THE *) 
(* MAIN ROUTINE. EACH WILL PRINT ONE LINE TO STANDARD OUTPUT. *) 
(* -— — *) 

PROCEDURE PROCl; 

BEGIN " PROCEDURE PROCl 

WRITELNC THIS LINE WRITTEN PROM PROCEDURE 1'); 
END; " PROCEDURE PROCl 

PROCEDURE PR0C2; 

BEGIN " PROCEDURE PR0C2 

WRITELNC THIS LINE WRITTEN PROM PROCEDURE 2'); 
END; " PROCEDURE PR0C2 

PROCEDURE PR0C3; 

BEGIN " PROCEDURE PR0C3 

WRITELNC THIS LINE WRITTEN PROM PROCEDURE 3'); 

END; " PROCEDURE PR0C3 

PROCEDURE PR0C4; 

BEGIN " PROCEDURE PR0C4 

WRITELNC THIS LINE WRITTEN PROM PROCEDURE 4'); 
END; " PROCEDURE PR0C4 

(» *) 

(» MAIN ROUTINE. SETS SEGMENT ID VARIABLES THEN CALLS OTHER *) 
(» SUBROUTINES. *) 

(* ^^ — -— -*) 

BEGIN 

INITSVC; (* INITIALIZE MAP SVC ») 

REWRITE (OUTPUT); (* OPEN OUTPUT, WRITE PIRST MSG *) 

WRITELNC THIS LINE WRITTEN PROM MAIN'); 

ROUTINE_NAME := 'PROCl '; (* MAP IN PROCl *) 

CHANGESEG( ROUTINE NAME); 

PROCl; ~ (* CALL PROCl *) 

ROUTINE_NAME := 'PR0C2 '; (* MAP IN PR0C2 *) 

CHANGESEGC ROUTINE NAME); 

PR0C2; ~ (* CALL PR0C2 ») 

ROUTINE_NAME := 'PR0C3 '; ( » MAP IN PR0C3 *) 

CHANGESEG( ROUTINE NAME); 

PR0C3; ~ (* CALL PR0C3 *) 

ROUTINE_NAME := 'PR0C4 '; (* MAP IN PR0C4 *) 
CHANGESEGC ROUTINE NAME); 

PR0C4; ~ (* CALL PR0C4 *) 

END. 



<<< MAIN2 LINK CONTROL >>> 

FORMAT IMAGE , REPLACE 
LIBRARY K.TIMIX.O 
LIBRARY .TIP. OBJ 
PROCEDURE RUNTIM 
INCLUDE (RUNTIM) 

PHASED, MAIN2 
INCLUDE (P$MAIN) 
INCLUDE (MAIN2) 
INCLUDE (SEGTBL) 

SEGMENT 3,SEG1,ID 5 
INCLUDE (PROCl) 
INCLUDE (PR0C2) 

SEGMENT 3,SEG2,ID 6 
INCLUDE (PR0C3) 
INCLUDE (PR0C4) 
END 



<<< RESULTS OP MAIN2 RUN >>> 

THIS LINE WRITEN PROM MAIN "~ 
THIS LINE WRITEN PROM PROCEDURE 1 
THIS LINE WRITEN PROM PROCEDURE 2 
THIS LINE WRITEN PROM PROCEDURE 3 
THIS LINE WRITEN PROM PROCEDURE 4 



DXPSCL 
MAINS 

PROGRAM MAINS; 
(* — 
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(* 
(* 
(* 
(* 
(* 
(* 
(* 
(* 
(* 
(* 
(* 
(* 
(* 
(* 
(* 

CONST 
(*___. 

(* 
(*— ■ 



TO 



THIS PROGRAM ILLUSTRATES THE USE OP DNOS SEGMENTATION 
MAP IN DIFFERENT DATA BLOCKS AND CONSERVE THOSE DATA 
BLOCKS BY ISSUING THE "SET EXCLUSIVE ACCESS" MAP CALL. 
NOTE THAT A NEW CHANGE SEGMENT ROUTINE IS PROVIDED THAT 
WILL SWITCH SEGMENTS BASED UPON THEIR RUNTIME ID'S. THIS 
IS DUE TO THE PACT THAT MEMORY BASED SEGMENTS DO NOT HAVE 
AN INSTALLED ID. 

THE PROGRAM ITSELF WILL MOVE A SERIES OP CONSTANTS TO THE 
DIFFERENT SEGMENTS AND THEN MAP THOSE SEGMENTS BACK IN AND 
PRINT THE DATA OBTAINED. THIS WILL ILLUSTRATE THAT THE 
CONTENTS OF THE SEGMENTS ARE PRESERVED WHILE THEY ARE NOT 
MAPPED IN TO THE TASK. ALSO NOTE THAT THE DATA SEGMENTS 
WILL ALL MAP AT THE SAME LOCATION SO THE POINTER TO THE 
SEGMENTS WILL BE SET ONLY ONCE DURING INITIALIZATION. 



COMMONLY USED CONSTANT DEFINITIONS 



■*) 

*) 

*) 

*) 

*) 

*) 

*) 

*) 

*) 

*) 

*) 
») 

*) 
*) 
*) 
*) 



■*) 
*) 
•*) 



MAP_SVC_CODE = #40; 

CODE_SEG_POS = S; 

MAP_FLAGS_POSIT = #C0; 

MAP_FLAGS_RESREL = #40; 

OWN_TASK_LUNO = #FP; 

" MAP SVC SUB OP-CODES: 

CHANGE_SEG = #00 

CREATE_SEG = #01 

RESERVE_SEG = #02 

RELEASE_SEG = #0S 

GET_SEG_STATUS = #04 

PORCE_WRITE = #05 

LOAD_SEG = #09 

UNLOAD_SEG = #0A 

SET_EXCLUSIVE = #0B 

RESET EXCLUSIVE = #0C; 



(* SVC CODE FOR MAP *) 

(* MAP POSITION FOR NEW SEGMENTS *) 

(* MAP FLAGS: MAP BY POSIT / LUNO *) 

(* MAP FLAGS FOR RESERVE/RELEASE *) 

(* LUNO FOR OWN PROGRAM FILE *) 



(* CHANGE SEGMENT *) 

(* CREATE SEGMENT *) 

(* RESERVE SEGMENT *) 

(* RELEASE SEGMENT *) 

(« GET SEGMENT STATUS *) 

(* FORCE WRITE SEG. ») 

(« MAKE SEG. MEMORY RESIDENT *) 

(* RELEASE MEMORY RESIDENT SEG. ») 

(» SET EXCLUSIVE USE OF SEG. *) 

(» RESET EXCLUSIVE USE *) 



TYPE 
(* 



*) 
•*) 



COMMONLY USED TYPE DEFINITIONS 



BYTE 
NAME 

SEGTBL_ENTRY 
PROC_NAME 
SEG_ID 
END; 



= 0..255; 

= PACKED ARRAY [1..6] OF CHAR; 

= PACKED RECORD; 
: NAME; 
: INTEGER; 



DXPSCL 
MAINS 

(*$ PAGE *) 
(* 

(* 

(* 
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DNOS 990 SEGMENTATION SVC FIELD DEFINITIONS 



•*) 
*) 
■*) 



T_MAPSVC 

SVC_CODE 

ERR_CODE 

OP_CODE 

MAP_LUNO 

MAP_FLAG 

MAP POS 

FILLl 

NEW_SEGID 

OLD_SEGID 

SEG_ADDR 

SEG_SIZE 

SEG_ATTRIB 

FILL2 
END; " T_MAPSVC " 

SEG_REC 
SEG_DATA 
END; 

VAR 

SEG_PTR 

SEG_TABLE 

STATUS 

COMMON 
MAPSVC 
MAP SVCB 
ENDJ " 



PACKED RECORD; 

BYTE: 

BYTE 

BYTE 

BYTE 

BYTE: 

BYTE: 

INTEGER; 

INTEGER; 

INTEGER; 

INTEGER; 

INTEGER; 

INTEGER; 

INTEGER; 



* SVC CODE = >40 *) 

* RETURNED ERROR CODE *) 

* MAP OP CODE *) 

* LUNO OF PROG FILE «) 
FLAGS *) 
MAP POSITION (0,1,2) *) 
FIRST WORD NEW SEG ID *) 
NEW SEGMENT *) 
OLD SEGMENT *) 
RETURNED ADDR OF SEG *) 
SIZE OF SEGMENT (I/O) *) 

* SEGMENT ATTRIBUTES *) 
» RESERVED *) 



= RECORD 

: ARRAY [1..100] OF INTEGER; 



@SEG_REC; (* POINTER TO SEGMENT DATA *) 

ARRAY C1..4] OF INTEGER; (« RUNTIME SEG ID *) 
INTEGER; 



RECORD 
T MAPSVC; 



PROCEDURE SVC$(SVC BLOCK : INTEGER); EXTERNAL; 



DXPSCL 
INITSVC 
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(*$ PAGE *) 
PROCEDURE INITSVC; 
(* 

(* 
(* 
(* 



THIS ROUTINE INITIALIZED THE MAP SVC BLOCK FOR GET EMPTY 
SEGMENT AND CHANGE SEGMENT CALLS BY RUNTIME ID. 



ACCESS MAPSVC; 

BEGIN " PROCEDURE INITSVC 
WITH MAPSVC, MAP_SVCB DO 

BEGIN " INITIALIZE MAP SVC BLOCK 



SVC_CODE 
MAP_LUNO 
MAP POS 



= MAP_SVC_CODE; 

= 0; 

= CODE SEG POS; 



PILLl := 0; 
OLD_SEGID := #FFPP; 
END; " INITIALIZE MAP SVC BLOCK 
END; " PROCEDURE INITSVC 



■*) 
*) 
*) 
■*) 



(* SET SVC CODE «) 

(* RUNTIME SEGMENTS ONLY *) 

(» MAP IN THIRD SEGMENT ») 

(* FIRST WORD NEW SEG TO ZERO ») 

(* INITIAL OUTGOING SEG TO -1 *) 



PROCEDURE SWITCHSEG(VAR SEG_ID 

VAR STATUS 
(» 

(* 

(* 
( » 

(* 
(* 



INTEGER 
INTEGER); 



THIS ROUTINE ISSUES THE MAP SVC SUPERVISOR CALL AFTER 
SETTING THE NEW SEGMENT ID AND TYPE OF MAP SVC (OP_CODE) . 
SOME ERROR PROCESSING IS ILLUSTRATED BUT WOULD MOST LIKELY 
BE INSUFFICIENT FOR MOST PROGRAMS. 



ACCESS MAPSVC; 

BEGIN " PROCEDURE SWITCHSEG 
WITH MAPSVC, MAP_SVCB DO 

BEGIN " INITIALIZE MAP SVC BLOCK 
OP_CODE := CHANGE_SEG; (* 
NEW_SEGID := SEG_ID; (* 

MAP FLAG := nS; 



SVC$(LOCATION(MAP_SVCB)); 
STATUS := ERR_CODE; 

END; " INITIALIZE MAP SVC BLOCK 
END; "'procedure SWITCHSEG 



SET FOR CHANGE SEG *) 
SET INSTALLED ID *) 
(* MEMORY BASED SEGMENT, *) 
(* EXCLUSIVE ON OUTGOING *) 
(* MAP IN SEGMENT *) 



■*) 
*) 
*) 
*) 
*) 
■*) 



DXPSCL 
CREATESEG 
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(*$ PAGE *) 

PROCEDURE CREATESEG (VAR SEG_ID 

VAR SEGADR 
VAR STATUS 
SIZE 
» . , 



INTEGER; 
INTEGER; 
INTEGER; 
INTEGER); 



( 

(* 

(* 

(* 

(* 

(* 

(* 

(*■ 



THIS ROUTINE ISSUES THE MAP SVC SUPERVISOR TO CREATE A 
MEMORY BASED SEGMENT. INPUT TO THE ROUTINE IS THE SIZE 
OP THE SEGMENT DESIRED. OUTPUTS ARE THE ADDRESS OP THAT 
SEGMENT AND THE RUN-TIME ID OP THE SEGMENTS. 
NOTE THAT THE SET EXCLUSIVE OPERATION IS ALSO ISSUED IN 
THIS ROUTINE TO INSURE SEGMENT IS NOT TRASHED BY 0/S. 



ACCESS MAPSVC; 

BEGIN " PROCEDURE CREATESEG 
WITH MAPSVC, MAP_SVCB DO 
BEGIN " CREATE SEGMENT 



OP CODE := CREATE SEG; 
NEW SEGID := SEG ID; 
MAP_PLAG := #18; 


(* 
(* 
(* 
(* 
(* 
(* 
(* 
(* 


SEG SIZE := SIZE; 
SEG_ATTRIB := #8420; 


SVC$( LOCATION (MAP SVCB)); 



SET FOR CHANGE SEG *) 
SET INSTALLED ID *) 
MEMORY BASED SEGMENT, *) 

EXCLUSIVE ON OUTGOING *) 
SET DESIRED SIZE ») 
READABLE, NON SYSTEM, *) 

SHARE PROT, EXEC PROT *) 
MAP IN SEGMENT *) 



INPO_ 
(* SET EXCLUSIVE USE 
(* MOVE SEG ID TO SEG 



*) 
*) 



IP (ERR_CODE = 0) THEN 

BEGIN "_RESERVE_&_RETURN SEG 
Op_CODE := SET_EXCLUSrvE; 
NEW SEGID := OLD_SEGID; 
SVClF( LOCATION (MAP_SVCB) ) ; 
IP (ERR_CODE = 0) THEN 
BEGIN " RETURN SEG INFO 

SEG_ID := OLD_SEGID; (* RETURN SEGID TO CALLER *) 
SEGADR := SEG_ADDR; 
END; " RETURN SEG INFO 
END; " RESERVE & RETURN SEG INFO 
STATUS := ERR_CODE; 
END; " CREATE SEGMENT 
END; " PROCEDURE CREATESEG 



•*) 
*) 
*) 
*) 
*) 
*) 
*) 
■*) 
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(*$ PAGE *) 

BEGIN 

(* -— ^ ~ -*) 

(* MAIN ROUTINE. MAPS POUR EMPTY SEGMENTS, MOVES 100 *) 

(» INTEGERS IN TO THE SEGMENTS, MAPS EACH SEGMENT BACK IN, *) 
(» THEN VERIFIES THE DATA IN THE SEGMENTS. *) 

(* *) 

INITSVC; (* INITIALIZE MAP SVC *) 

REWRITE (OUTPUT); (* OPEN OUTPUT, WRITE FIRST MSG *) 

FOR I := 1 TO 4 DO 

BEGIN " CREATE AND PILL EMPTY SEGMENTS 

CREATESEG(SEG_TABLE[I], SEG_PTR: : INTEGER, STATUS, 200); 
IF STATUS = THEN 
FOR J := 1 TO 100 DO 

SEG_PTR@.SEG_DATA[J] := I 
ELS^ 
"WRITELNC ERROR IN MAPPING SEGMENT; ERROR CODE = ', 
STATUS: 4); 
END; " CREATE AND PILL EMPTY SEGMENTS 

IP STATUS <> THEN ESCAPE MAIN3; 

FOR I := 1 TO 4 DO 

BEGIN " REMAP SEGMENTS AND VERIFY SEGMENT CONTENTS 
SWITCHSEG ( SEG_TABLE [ I ] , STATUS ) ; 
IF STATUS = THEN 
VS: BEGIN " VERIFY SEGMENTS 
FOR J := 1 TO 100 DO 

IF SEG_PTR@.SEG_DATA[J] <> I THEN 
BEGIN " WRITE MESSAGE 

WRITELNC SEGMENTS DO NOT VERIFY '); 
ESCAPE VS; 
END; " WRITE MESSAGE 
WRITELN ( ' SEGMENT NUMBER ',1:1,' VERIFIED ' ) ; 
END " VERIFY SEGMENTS 
ELSE 

WRITELNC ERROR IN MAPPING SEGMENT NUMBER ',1:1, 
' ; ERROR CODE = ' , STATUS : 4 ) ; 
END; " REMAP SEGMENTS AND VERIFY SEGMENT CONTENTS 
END. 



<<< MAINS LINK CONTROL >>> 
FORMAT IMAGE, REPLACE 
LIBRARY K.TIMIX.O 
LIBRARY .TIP. OBJ 
PROCEDURE RUNTIM 
INCLUDE (RUNTIM) 

PHASED, MAINS 
INCLUDE (P$MAIN) 
ALLOCATE 
INCLUDE (MAINS) 
END 



f <« RESULTS OP MAINS RUN >>> 

1 

If 

H 

If 

If 

If 

If 

If 

If 

If 

f 



SEGMENT NUMBER 1 VERIFIED 

SEGMENT NUMBER 2 VERIFIED 

SEGMENT NUMBER S VERIFIED 

SEGMENT NUMBER 4 VERIFIED 
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PAGE 0002 



0002 

0003 
0004 

0005 
0006 

0007 
0008 
0009 
0010 
0011 
0012 
0013 
0014 
0015 
0016 

0017 
0018 

0019 
0020 
0021 
0022 

0023 
0024 
0025 
0026 
0027 
0028 

0029 
0030 
0031 
0032 
0033 
0034 

0035 
0036 

0037 

0038 
0039 
0040 
0041 

0042 
0043 
0044 

0045 
0046 

0047 
0048 

0049 

0050 

0051 
0052 
0053 
0054 

0055 



0000 
0000 
0052 



0000 

0000 
0002 
0004 
0004 
0006 
0008 
OOOA 
OOOC 
OOOE 
0010 
0012 
0014 
0016 
0018 
OOIA 
OOIA 
OOIC 
OOIE 
0020 
0020 
0022 
0024 
0026 



0000" 
0004' 

C09D 

C032 

0280 

0004 

1622 

C0F2 

C112 

04D4 

0205 

0000+ 

C0B5 

0200 
0006 
0043 

8075 
1611 
0640 
16FC 



IDT 'MAPSEG' 
CSEG 'SEGTBL' 
SEGTBL BSS 2+(10»8) 
CEND 



THIS ROUTINE TAKES A SIX-CHARACTER SUBROUTINE NAME 
PASSED AS AN ARGUMENT AND LOADS THE ASSOCIATED SEGMENT 
IF THAT SEGMENT IS NOT ALREADY IN MEMORY. THIS 
ROUTINE REFERENCES THE COMMON "SEGTBL" FOR THE NAMES 
AND SEGMENT ID'S OF THE SEGMENTS. 

CALLING SYNTAX: 

WORKING-STORAGE SECTION. 

01 SEG-NAME-1 PIC X(6) VALUE "PROCl " 

01 STATUS PIC 9(4) COMP-1. 



CALL "MAPSEG" USING SEG-NAME-1, STATUS. 

RETURN STATUS: 

>FFFF: SUBROUTINE NAME NOT FOUND IN LIST 
ALL OTHERS: MAP SVC ERROR CODE (AS INTEGER) 

REGISTER USAGE: 

RO - SCRATCH 

Rl - WORKING COPY OF DESIRED ROUTINE NAME 

R2 - COUNT ENTRIES IN SEGTBL COMMON 

R3 - ADDRESS OF DESIRED ROUTINE NAME 

R4 - ADDRESS OF RETURN STATUS CODE 

R5 - INDEX INTO SEGTBL COMMON 



DXOP SVC, 15 
MAPSEG EVEN 

DEF MAPSEG 
DATA WS,MAPOOO 

MAPOOO EVEN 

MOV *R13,R2 
MOV »R2+,R0 
CI R0,4 



JNE 
MOV 
MOV 
CLR 
LI 



MAPXIT 

»R2+,R3 

*R2,R4 

*R4 

R5, SEGTBL 



MOV *R5+,R2 
MAPOIO EVEN 

LI R0,6 

MOV R3,R1 
MAP020 EVEN 

C *R5+,*R1+ 
JNE MAP060 
DECT RO 
JNE MAP020 



GET ADDRESS ARGUMENT LIST 
GET BYTE LENGTH OF ARGS 
IF NOT TWO, JUST RETURN 

GET ADDRESS OF SEGMENT NAME 
GET ADDRESS OF STATUS FIELD 
ASSUME NO ERRORS NOW 
GET ADDRESS OF SEGMENT TABLE 

GET NUMBER ENTRIES IN SEGTBL 

SET BYTE LENGTH OF NAME 

WORKING COPY ROUTINE NAME 

SAME NAME 

NO, TO NEXT ENTRY 

REDUCE BYTE COUNT 
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0057 
0058 

0059 0028 

0060 0028 
002A 

0061 0020 

0062 002E 
0030 

0063 0032 
0034 

0064 0036 
0038 

0065 003A 
0030 

0066 003E 

0067 0040 
0042 

0068 0044 

0069 0046 

0070 0046 

0071 
0072 
0073 
0074 

0075 0046 

0076 0048 

0077 004A 
0078 

0079 0040 
004E 

0080 0050 

0081 0050 

0082 0052 

0083 0052 

0084 0054 

0085 0054 

0086 0000 

0087 0000 

0088 0020 

0089 0020 

0090 0020 

0091 0022 

0092 0023 

0093 0024 
0094 

0095 

0096 0026 

0097 0028 

0098 002A 

0099 0020 

0100 002E 

0101 0030 

0102 0032 
NO ERRORS, 



8815 

0028" 

1312 

0815 
0028" 

2FE0 

0020" 

0020 

0020" 

0240 

OOFP 

1309 

04E0 

0028" 

1005 



*R5,@NEWSEG 

JEQ MAPXIT 

MOV *R5,@NEWSEG 

SVO @MAPSVO 

MOV @MAPSVO,RO 

ANDI RO,>OOPF 

JEQ MAPXIT 

OLR @NEWSEG 

JMP MAPERR 



<<< HAVE MATCHING NAME IP HERE 
R5 POINTS TO SEG ID 

IS THIS SEGMENT ALREADY IN 

YES: DONE NOW 

NO: SET SEGMENT ID 

ISSUE MAP SVO 

TEST ERROR OODE 



NO ERROR: NORMAL EXIT 
ERROR: SET NO SEG IN 

RETURN SETTING ERROR OODE 



MAP060 EVEN 

* 

« 

A140 A 
0602 DEC 
16E7 JNE 

0200 LI 
FFPF 

MAPERR EVEN 
C500 MOV R0,*R4 

MAPXIT EVEN 

0380 RTWP 

PEND 



IP HERE, RO IS 2 MORE THAN REMAINING LENGTH OF 
NAME. BY ADDING RO, WILL SKIP OVER REST OP NAME 
AND SEGMENT ID FIELD. 



R0,R5 
R2 

MAPOIO 
RO,>PPPF 



SELECT NEXT ENTRY 
LOOP FOR NEXT NAME 

<<< NO MATCH IP HERE 
SET ERROR CODE 



RETURN ERROR CODE 
RETURN TO CALLER 



WS 



DSEG 
BSS 



MAP SVC EVEN 

4000 DATA 

00 BYTE 

FP BYTE 

C003 DATA 

* 

0000 DATA 
0000 NEWSEG DATA 
0000 DATA 
0000 DATA 
0000 DATA 
0000 DATA 
DEND 
NO WARNINGS 



32 



>4000 
>00 
>PP 
>C003 






$-$ 
$-$ 
$-$ 





MAP SVC BLOCK 
SVC CODE 

OP-CODE = CHANGE SEG 
LUNO = OWN PROGRAM FILE 
FLAGS: MAP BY LUNO, 
INSTALLED ID, 
MAP POSITION 3 
NEW SEGMENT ID (WD 1) 
(WD 1) 
RETURNED SEG ADDRESS 
RETURNED SEG LENGTH 
RETURNED SEG ATTRIBUTES 
RESERVED 
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LINE DEBUG PG/LN A 



1 IDENTIFICATION DIVISION. 

2 PROGRAM-ID. COBMAN. 

3 AUTHOR. S. KEN CULP. 

4 ENVIRONMENT DIVISION. 

5 CONFIGURATION SECTION. 

6 SOURCE-COMPUTER. TI-990-10. 

7 OBJECT-COMPUTER. TI-990-10. 

8 INPUT-OUTPUT SECTION. 

9 PILE-CONTROL. 

10 SELECT LIST-FILE ASSIGN TO PRINT, "OUTPUT". 

11 DATA DIVISION. 

12 PILE SECTION. 

13 FD LIST-FILE LABEL RECORDS OMITTED. 

14 01 DATA-RECORD PIC X(34). 

15 WORKING-STORAGE SECTION. 

16 01 SEQ-RECORD. 

17 02 HEADER PIC X(28) VALUE 

18 " PROCEDURE NAME ENTERED IS: ". 

19 02 PROC-NAME PIC X(6). 

20 01 SNL PIC X(6). 

21 01 MAP-STATUS PIC 9(5) COMP-1. 

22 01 PROCl-NAME PIC X(6) VALUE "PROCl ". 

23 01 PR0C2-NAME PIC X(6) VALUE "PR0C2 ". 

24 01 PR0C3-NAME PIC X(6) VALUE "PR0C3 ". 

25 01 PR0C4-NAME PIC X(6) VALUE "PR0C4 ". 

26 PROCEDURE DIVISION. 

27 >0000 MAIN-01. 

28 >0000 OPEN OUTPUT LIST-PILE. 

29 >0006 MOVE "MAIN " TO PROC-NAME, 

30 WRITE DATA-RECORD FROM SEQ-RECORD. 

31 >00l6 CALL "MAPSEG" USING PROCl-NAME, MAP-STATUS. 

32 >0018 IF MAP-STATUS = ZERO 

33 CALL "PROCl" USING SNL, 

34 MOVE SNL TO PROC-NAME, 

35 WRITE DATA-RECORD FROM SEQ-RECORD. 

36 >0030 CALL "MAPSEG" USING PR0C2-NAME, MAP-STATUS. 

37 >0032 IP MAP-STATUS = ZERO 

38 CALL "PR0C2" USING SNL, 

39 MOVE SNL TO PROC-NAME, 

40 WRITE DATA-RECORD FROM SEQ-RECORD. 

41 >004A CALL "MAPSEG" USING PR0C3-NAME, MAP-STATUS. 

42 >004C IF MAP-STATUS = ZERO 

43 CALL "PR0C3" USING SNL, 

44 MOVE SNL TO PROC-NAME, 

45 WRITE DATA-RECORD FROM SEQ-RECORD. 

46 >0064 CALL "MAPSEG" USING PR0C4-NAME, MAP-STATUS. 

47 >0066 IF MAP-STATUS = ZERO 

48 CALL "PR0C4" USING SNL, 

49 MOVE SNL TO PROC-NAME, 

50 WRITE DATA-RECORD PROM SEQ-RECORD. 

51 

52 >007E CLOSE LIST-PILE. 

53 ZZZZZZ END PROGRAM. *** END OP FILE 



DNCBL 



3.3.3 81.280 COMPILED: 02/08/83 13:37:40 OPT= 



PAGE 



LINE DEBUG PG/LN A...B 



1 
2 
3 
4 
5 
6 

7 
8 

9 
10 
11 
12 

13 
14 
15 
16 



>0000 
>0000 
>0006 
>0006 



NOTE: 



IDENTIFICATION DIVISION. 
PROGRAM-ID. PROCl. 
AUTHOR. S. KEN GULP. 
ENVIRONMENT DIVISION. 
CONFIGURATION SECTION. 
SOURCE-COMPUTER. TI-990-10. 
OBJECT-COMPUTER. TI-990-10. 
DATA DIVISION. 
LINKAGE SECTION. 
01 SNL PIC X(6). 

PROCEDURE DIVISION USING SNL. 
MAIN-01. 

MOVE "PROCl " TO SNL. 
MAIN-02. 

EXIT PROGRAM. 
ZZZZZZ END PROGRAM. 



*** END OF FILE 



PROCEDURES CPR0C2, CPR0C3, AND CPR0C4 ARE THE SAME AS THIS PROC 
EXCEPT FOR RETURNED STRING IN SNL AND NAME OF ROUTINE. 



<<< MAIN LINK CONTROL >>> 

FORMAT IMAGE, REPLACE 

NOAUTO 

LIBRARY K.TIMIX.O 

LIBRARY .S$SYSLIB 

PROCEDURE CRUNTM 

INCLUDE (RCBPRC) 



<<< RESULTS OF MAIN RUN >>> 



PHASEO, 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 
INCLUDE 



CMAINl 

(RCBTSKD) 

(RCBMPD) 

(COBMAN) 

(MAPSEG) 

(SEGTBL) 



SEGMENT 3,SEG1,ID 7 
INCLUDE (CPROCl) 
INCLUDE (CPR0C2) 

SEGMENT 3,SEG2,ID 8 
INCLUDE (CPR0C3) 
INCLUDE (CPR0C4) 
END 



PROCEDURE NAME 
PROCEDURE NAME 
PROCEDURE NAME 
PROCEDURE NAME 
PROCEDURE NAME 



ENTERED iS : MAIN 

ENTERED IS: PROCl 

ENTERED IS: PR0C2 

ENTERED IS: PR0C3 

ENTERED IS: PR0C4 



OPERATING SYSTEM SUPPORT 
FOR ASYNCHRONOUS TERMINALS 

OPERATING SYSTEMS 



Daniel Gillen 
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INTRODUCTION 

A Device Service Routine (DSR) must provide support for 
two hardware units, the peripheral device and the 990 chassis 
resident controller. A DSR structure will be discussed which 
separates the software support for these units into two major 
DSR code elements. The first is a Peripheral Service Routine 
(PSR) module providing support for the peripheral device 
independent of the controller. The second is a Hardware 
Service Routine (HSR) providing controller support. 

The goals leading to the DSR design and the problems 
addressed by the design are presented. The DSR structure will 
be discussed in terms of functionality, logic and data flow 
and module interfaces. A specific implementation will be 
presented as an example of the design philosophy. 



TERMINOLOGY 



At Texas Instruments the peripheral device support 
software is linked with the operating system and is called a 
Device Service Routine (DSR). The DSR provides a software 
interface between the application software and the peripheral 
hardware. Two terms key to this discussion are controller and 
peripheral device. These terms will be defined in a somewhat 
restricted way for purposes of this paper. The definitions 
are oriented around Texas Instruments Business System 
p roduc t s . 

Peripheral Device 

Peripheral device is the term used to refer to input and/or 
output hardware capable of being connected to a computer. My 
use of this term assumes a separate hardware unit, a 
controller, is required to interface this peripheral device to 
the computer. The terms peripheral device, device and 
peripheral will be used interchangeably in this paper. 

Controller 

A controller is a hardware unit which interfaces directly to a 
CPU. Typically the controller is a printed circuit board 
which resides in the computer chassis. Two types of 
controllers will be considered for Texas Instruments Business 
Systems, CRU controllers interfacing to the Communications 
Register Unit (CRU) and TILINE controllers interfacing to the 
TILINE data bus. This paper will consistently use the term 
controller for this hardware unit though historically many 
other terms have been used. Some of these other terms include 
interface, interface module, board and card. 
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A few examples are listed here for purposes of clarification. 
Texas Instruments Business Systems peripheral devices: 

1. Omni 800 Model 810 printer 

2. Opti 900 Model 940 Video Display Terminal 

3. WD800 Winchester Disk Drive 

Texas Instruments Business Systems controllers: 

1. CI421 - S300 Two Channel Communications Option Board 

2. CI401 - S600/S800 Communications Interface Module 

3. TPBI - S600/S800 TILINE Peripheral Bus Interface 

4. TMS9902 UART on the 990/ lOA and S300 processor 
boards 



DSR STRUCTURE 

Three major functional levels exist between an 
application and an I/O peripheral device. The application 
interfaces to an Input/Output subsystem which, in turn, 
interfaces to I/O device hardware. 

APPLICATION < > I/O SUBSYSTEM < > I/O DEVICE 

Looking one level lower at the I/O subsystem structure we see 
essentially three separate functions being performed. The 
operating system pre-processes the application request before 
passing the request to a DSR. The DSR executes the I/O 
request then passes it to the operating system post processing 
element which reports completion to the application. This 
process is illustrated as follows. 

nc T3Di?_r>T>nr'T?ccT\rr! S "nQP S OR POST- PROCR S S ING 

Looking still one level lower at the DSR we have three more 

interfaces. There is an interface to the operating system, an 

interface to the I/O device and an interface to the controller 
illustrated as follows. 
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OS I/F < > DEVICE I/F < > CONTROLLER I/F 



This paper analyzes the DSR structure. The three 
functions of the DSR will be given names. The operating 
system interface will be denoted OSI. The peripheral device 
interface will be called a Peripheral Service Routine (PSR) 
and the controller interface will be called a Hardware 
(Controller) Service Routine (HSR). Figure 1 pictures the 
levels of a Device Service Routine (DSR). 



OPERATING SYSTEM 

1 
+ + 

OSI 
PSR 
HSR 



DSR 



HARDWARE 



Figure 1 DSR STRUCTURE 



Table 1 lists examples of software elements at the 
various levels. Each column of the table identifies a class 
of software. The column entries indicate specific examples 
within the class. The key point to consider in the table is 
that a unique path from application to I/O device is defined 
by choosing one entry from each column. The table has only a 
few entries for each column but it should be apparent that 
there are a large number of paths when all possible 
combinations are considered. Several issues deserve mention 
relative to the table. 

The OSI level does not appear explicitly as a separate 
column in Table 1. The OS interface to the two operating 
systems is very similar and our implementation did not include 
a separate module for the OS interface. The the OS interface 
logic is embedded in the PSR for this implementation. Assume, 
for purposes of this discussion, the two operating systems are 
identical. This is an over simplification but will allow us 
to concentrate on other DSR interfaces. 
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Table 1 SOFTWARE ELEMENTS 
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Advantages of isolating controller suppor 
module and device support to the PSR should be obv 
one software module is required for each device 
each controller. This pays dividends in developme 
as in sustaining during the life of the product, 
applications have an identical, ignoring the 
interface across all controllers. When a group o 
devices are supported by DSR's using this design, 
support may easily be moved to a new controller, 
module must be developed to support all curren 
devices on a new controller. 
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The key to the design is the definition of the interface 
to the HSR. The first step taken was to bound the problem. 
The goal was to develop an interface scheme for asynchronous 
peripheral devices. Thus, the set of controllers was limited 
to asynchronous controllers. Next, a set of functions 
supported by asynchronous controllers was compiled. Finally, 
a generic interface was specified to provide access to these 
controller functions. 

The specification of the generic interface was an 
iterative process and had to satisfy several parameters. Some 
key parameters included: 

1. Controller independence 

2. Access to full controller functionality 

3. Emulation of buffered controller for output 

4. Provide PSR required services 
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The decision to emulate a buffered controller was based 
partially on experience gained supporting non buffered 
controllers. The buffering referred to here is not the one or 
two character buffering typically done by UART chips but 
buffers in the 32-128 character range. The purpose was to 
allow better separation between PSR and HSR output processing. 
One benefit of this approach was minimizing the amount^ of 
output processing with interrupts masked. This is a critical 
issue for VDT's where the ratio of output data to input data 
at the CPU is heavily weighted in the output direction. 

The functions supported by the HSR are numerous. They 
can be grouped into the following classes. 

1. Controller initialization. 

2. Read/write operational parameters. 

3. Set/reset output signals or functions. 

4. Read input signals or functions. 

5. Status change notification. 

6. Read/write data characters. 

7. Timer services. 

8. Controller interrupt processing. 

AN IMPLEMENTATION 

Now an implementation of a set of Device Service Routines 
(DSR's) will be discussed. The DSR's fit the basic structure 
introduced in the previous portion of the paper. They 
supported asynchronous devices attached to asynchronous 
controllers. The emphasis will be on logic flow and software 
interfaces. Figure 2 illustrates the DSR structure, logic and 
data flow. This implementation separated the PSR level into 
two modules. One will be referred to as the TSR and the other 
as the Interrupt Service Routine (ISR). Table 2 indicates 
f: 4--:^„<, «-=,vfr^v™^^ Kv f-hp DSR modules for this 

implementation. 
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Table 2 DSR FUNCTIONS 

TSR - TERMINAL - All DSR entry points except interrupt entry 
SERVICE ROUTINE ( Reques t/ Init ia 1 , Power up , Abort , Timeout , and 

Delayed Reentry) 

- Request and completion reporting I/F to OS 

- Runs in PDT workspace 

- Provides software interface to terminal 

- Terminal dependent logic 

ISR - INTERRUPT - Contains interrupt entry of the DSR 

SERVICE ROUTINE - I/F to HSR for interrupt processing 

- High priority receive character processing 

- Runs in DSR interrupt workspace 

HSR - CONTROLLER - Generic (subroutine) software interface 

SERVICE ROUTINE to the controller hardware 

- Contains all controller dependent logic 

- Contains all direct access to controller 
~ Emulation of buffered controller 

* Software FIFO's 

- Maintains controller status and statistics 
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Figure 2 DSR LOGIC FLOW 



The TSR module contains all DSR entry points except the 
interrupt entry. It accepts requests from the OS and reports 
completions to I/O subsystem of the OS. The primary function 
of the TSR is to provide a software interface to the 
peripheral device. The actual functions vary considerably 
based on the type of device. The primary device types 
supported in this implementation were VDT's, and serial 
printers. The TSR combined with the ISR to support the 
peripheral device. 
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Read requests are processed, by the TSR, entirely from a 
receive character queue. The receive data characters are 
stored in this character queue by the ISR routine. Other 
requests are processed primarily by the TSR with the aid of 
the ISR if required. 
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For the most part, ISR processing is independent of 
request processing of the DSR. Receive data is stored in the 
receive character queue even when no read request is active at 
the DSR. Error recovery action must be taken when the receive 
character queue becomes full. The ISR processes events 
requiring immediate attention. Some examples of ISR 
processing for keyboard devices are biding an application 
task, halting output, aborting I/O and aborting tasks. It 
also schedules TSR level elements to start or resume 
process ing. 
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The HSR level does not support the concept of a read 
request. The HSR will decode the controller Interrupt and 
report the cause for the interrupt to the ISR. If the cause 
of the interrupt was a received data character, the data 
character is also passed back to the ISR. There is no storage 
of receive data at the HSR level. 

The generic interface to the HSR consists primarily of 
two mechanisms. The HSR is a set of subroutines with a branch 
and link (BL) call interface. A subroutine implements one or 
more generic functions for the specific controller in use. A 
"set DTR" subroutine call is made by the TSR. The HSR for a 
CRU controller might implement this as a "SBO DTR" GRU 
instruction but the HSR for a TILINE controller might 
implement the same subroutine using a "SOC (SDTR, (a0UTSIG( Rl 2) " 
instruction to access the TILINE Peripheral Control Space 
(TPCS) for the controller. Identical requests from the 
TSR/ISR will invoke identical functions for all controllers. 
Provision is made for controller hardware differences. A not 
supported" return is provided for each HSR routine. This 
return is taken when the requested function is not supported 
by the controller hardware. 




MOV @PDTHSR(R4) ,R5 
MOV @SETDTR(R5) ,R6 

places the "set DTR" subroutine address in R6. When R4 
contains the address of the PDT and PDTHSR. is the Index of the 
HSR branch table pointer from the start of the PDTe 
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1 INTRODUCTION 

File security will be available as a SYSGEN option with 
DNOS 1.2. It will complement existing DNOS security features 
such as logon passcodes, user IDs and SCI privilege levels. 
The system is designed to be effective in a cooperative 
environment and easy to use. It will have little or no effect 
on users who choose not to include it in their system. Using a 
set of new SCI commands, a user will be able to define groups 
of users and specify which groups of users may access his 
files, as well as how the files may be accessed. The ability 
to secure program files, batch streams, SCI command procedures 
(procs), and data files provides a system manager with a high 
level of control over access to sensitive system components. 

This paper introduces the scope, concepts, and 
functionality of DNOS file security from the point of view of 
the user. An illustration is provided as an example to clarify 
several important new concepts. These concepts are 
interrelated and must be understood before one can establish a 
secure environment. 



2 SCOPE AND PURPOSE 

DNOS file security provides a means to prevent access or 
destruction of secured files by unauthorized individuals. The 
extent to which this is successful depends on at least three 
factors: the skill and determination of the individual, the 
software tools available to him, and physical security 
measures. It would be difficult, if not impossible, to design 
a security system that would protect against a determined 
attempt by a skilled individual with access to powerful tools 
such as the SCI debugger. Physical security measures appear to 
be much more effective against this type of security threat. 
On the other hand, a reasonably effective level of security 
protection can be achieved by controlling access to the system, 
controlling access to powerful tools, and placing control of 
this access in the hands of responsible individuals. 
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CONCEPTS 



There are several aspects of DNOS file security that must 
be understood separately. The two most important are the 
concepts of access groups and access rights. Access to a file 
is granted or denied based on the relationship between the 
access groups associated with a user and the access rights 
associated with a file. Access groups and access rights are 
defined and discussed below. 



3.1 Access Groups. 

An access group is simply a group of users. Users 
associated with an access group are called members of that 
access group. Any user can create an access group and specify 
which users are members of that group. When a file is secured, 
one specifies which type of access will be granted to which 
access groups. 



3.2 Access Rights. 

There are five access rights: read, write, delete, 
execute, and control. An access group may be given any 
combination of these access rights. A new SCI command will be 
available to assign and modify access rights to individual 
f i les . 

Read access is more than just the right to read data from 
a file. If the file is an SCI batch stream or procedure, read 
access is the right to execute the batch stream or the 
procedure. Read access on a program file allows a user to 
issue the Map Program File (MPF) SCI command. 



Write access is the right to write data 
includes the ability to write over the existing 
write new data. Write access to a program file 
right to install or delete tasks, segments, 
overlays. Write access to a key indexed file 
right to delate records from that file. 

Execute access only has meaning when it is 

o T%-^/^^v>om fila J t- r-or»rf»epnt-s t-he> ri?ht tO 
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program f i les . 
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Delete access is the right to delete a file. Delete 
access is also required in addition to write access to text 
edit a file. 

Control access is the right to change the security 
associated with a file. This includes the right to change the 
set of access groups associated with a file, as well as change 
the access rights associated with each access group. Each 
secured file has one and only one access group with control 
access . 



3.3 Access to a Secured File. 

Each secured file can have access rights for as many as 
nine access groups. A different set of access rights can be 
defined for each access group. The access rights associated 
with an access group determine how the members of that access 
group can access the file. For example, assume a secured file 
has the read access right for the access group named MANAGER. 
Any user who is a member of the access group named MANAGER is 
granted read access to the file. Establishing access group 
membership and access rights for a file will be discussed in 
detail later. 

A user's access groups are established at the time he logs 
on. Any changes to his access group membership are recorded on 
disk and do not take effect until the next time he logs on. 

Access rights to a file are established when a LUNO is 
assigned. Any changes to the access rights associated with a 
file will not affect access rights through LUNOs currently 
assigned. Access rights are checked for each individual file 
operation and are enforced only for files. They have no 
meaning for directories. Any attempt to secure a directory 
will result in an error. 



3.4 The Access Group Leader. 

When an access group is created, the creator becomes the 
leader of the access group. The leader of an access group has 
the right to add users to the access group, delete users from 
the access group, assign leadership of the access group to 
another user, or delete the access group. Only one leader is 
allowed for each access group. If leadership is assigned to 
another user, that user becomes the only leader. 
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3.5 Predefined Access Groups. 

There are two predefined access groups that exist on all 
secured systems. They are named PUBLIC and SYSMGR. 

PUBLIC is an access group which has all users as members. 
It has no leader. It cannot be deletedj and its membership 
changes automatically as user IDs are added or deleted from the 
system. A secured file is unsecured by specifying all access 
rights for the access group named PUBLIC 

SYSMGR is an access group which is created automatically 
and can never be deleted. Any user who is a member of SYSMGR 
has full access to any file and leadership capabilities for any 
access group. Due to the nature of this access group, members 
of SYSMGR cannot be a member of any other access group. 



3.6 File Creation Access Group. 

Every user has an associated file creation access group. 

If one has not been specified, PUBLIC is assumed. When a file 

is created, all access rights are assigned for the file 

creation access group of the creator. If a user's file 
creation access group is PUBLIC, all files he creates will be 

unsecured. There is an SCI command which allows a new file 
creation access group to be defined. 



OVERVIEW OF A SECURED SYSTEM 



A simplified representation of a secured system is 
illustrated on the following page. The system has only two 
access groups and three files. The example depicts the 
relationship between membership in an access group and access 
rights to a secured file. The paragraphs following the 
illustration describe the details of this relationship. 
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SIMPLE SECURED SYSTEM 
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The access group named MANAGERS has members Fred and Mary. 
The access group named CLERKS has members Betty, Fred, and 
Bill, The files named SALES and PAYROLL have access rights 
defined for MANAGERS and CLERKS. The file which contains the 
INV proc has access rights defined only for MANAGERS. 

Mary can write to the file named PAYROLL because she is a 
member of the access group named MANAGERS and write access is 
defined for that access group. However, if Mary attempts to 
write to the file named SALES, she will get an error because 
she is not a member of any access group with write access to 
the file. It is important to note that if Mary really needed 
to write to the file named SALES, she could issue the command 
to change her access rights. She can issue that command 
because she is a member of the access group named MANAGERS and 
control access is defined for that access group. Similarly, 
Bill can write to the file named SALES because he is a member 
of the access group named CLERKS and write , access is defined 
for that access group. However, if Bill tried to write to the 
file named PAYROLL he would get an error because he is not a 
member of an access group with write access to that file. If 
he really needed to write to the file named PAYROLL, there are 
two things he can do. He could ask the leader of the access 
group named MANAGERS to make him a member of that access group 
or he could ask any member of the access group named MANAGERS 
to change the security on the file to give write access to an 
access group of which Bill is a member. Bill is a new employee 
and likes to try new commands. Luckily, when he tries the INV 
command he will get an error because he is not a member of an 
access group with read access to the INV proc. 



5 USER INTERFACE 

A set of new SCI commands is provided for file security. 
Most require the user to verify his identity by entering his 
logon passcode. SCI will not echo the password either 
interactively or in the batch stream listing. Passwords 
imbedded in batch streams may be represented by a synonym and 
must be protected by file security on the batch stream and 
lis ting. 



5.1 Access Group Commands. 
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Several SCI commands are provided for creating, deleting, 
listing, and changing the membership of access groups. Most 
can only be issued by the leader of the access group. An 
attempt to issue a command which requires leadership by anyone 
other than the leader will result in an error. 

Access groups are created by issuing the Create Access 
Group (CAG) command. Any user who has access to the proc can 
issue the CAG command. The access group will be created and 
the user issuing the command will become the leader. 

Only the leader of an access group can issue the Modify 
Access Group (MAG) command. The command is used to add users 
to the access group, delete users from the access group, or 
assign a new leader of the access group. Each user ID to be 
added and the new leader's user ID must be valid. 

Only the leader of an access group can issue the List 
Access Group Members (LAGM) command. It lists user IDs of all 
users which are members of the access group. 

Only the leader of an access group can issue the Delete 
Access Group (DAG) command. It is the responsibility of the 
user issuing the command to insure that no files exist which 
permit access only to this access group. If such a file is 
accidentally overlooked, it becomes accessable only to the 
SYSMGR access group. 

Any user may issue the List Access Group(LAG) command. It 
lists all access groups of which the user is a member. The 
output will indicate which access group is the user's file 
creation access group and those groups for which the user is 
the leader. 

Any user may issue the Set Creation Access Group (SCAG) 
command. It allows a user to specify which access group will 
automatically have full access to files he may create. The 
user must be a member of any access group he specifies as a 
file creation access group. To prevent conflict between batch 
or background and foreground SCI file creation, this command 
updates the creation access group recorded on disk. The new 
file creation access group is not effective until the next time 
a user logs on under that user ID. 

5.2 Access Rights Commands. 

There are two commands provided to manipulate access 
rights. They list or modify the access groups and their 
corresponding access rights for an individual file. To issue 
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these commands, one must be a member of an access group with 
the control access right to the file. 

The List Security Access Rights (LSAR) command lists the 
access groups and access rights associated with a particular 
file. The user must enter his logon passcode to verify his 
identity. The user specifies the file pathname and the output 
displays all access groups with access rights to the file. It 
also indicates which access rights are associated with each 
access group. 

The Modify Security Access Rights (MSAR) command modifies 
the security on an individual file. It prompts the user for 
his logon passcode to verify his identity. The user specifies 
the file pathname, access group name, and which access rights 
are to be given to the access group. If the access group named 
PUBLIC is entered and all access rights are specified, the file 
becomes unsecured. 



IMPACT TO EXISTING APPLICATIONS 



Existing applications and utilities can be adapted to run 
in a secure environment with no code changes. There are 
different approaches to establishing a secure environment for 
an application. One can secure the application program, secure 
the files it accesses, or both. Which approach one chooses 
will depend on the nature of the application or utility. 
Utilities such as Initialize New Volume (INV) are inherently 
powerful and should be secured. Utilities such as Show File 
(SF) can probably be unsecured but protection on individual 
files will limit what files can be shown. 



6.1 Securing An Application. 

To control access to a powerful application or utility one 
can secure the program file, command procedure, batch streams, 
or any combination of these. This may be accomplished by 
creating an access group and adding as members, each user ID 
which can access the application. Execute access must be 
specified for this access group on the program file. Read 

the batch stream. 
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6.1,1 Securing Sensitive Files. 

There are two things that must be considered when securing 
sensitive files. One must insure that unauthorized users 
cannot access the file. One must also insure that applications 
or utilities that must access the file have the necessary 
access rights to do so. 

There are two categories of applications from the point of 
view of file security: applications that run in their own job, 
and applications that run in the user's job. The steps 
involved in establishing a secure environment depend on the 
category of the application. 

Applications or utilities that run in their own job will 
automatically inherit the access rights of the user ID of the 
job. One must create an access group with that user ID as a 
member. One must also insure that all files the application 
must access are permitted to that access group with the 
appropriate access rights. 

Applications or utilities that run in the user's job will 
inherit the access groups of the user. Any attempt by the 
application or utility to access a file in a way not allowed 
for the user will result in an error. 



6.2 Security Bypass. 

In certain circumstances it may be desirable for an 
application or utility to have access to a file but undesirable 
to give that access to a user. For example, a data base may be 
maintained by an application. The application needs write 
access to the data base files; However, it may be undesirable 
to give write access to users because that allows them to write 
to the file with programs other than the application which 
manages the data base. A new task attribute called security 
bypass is provided for circumstances such as this. A task that 
is installed with security bypass will be granted all access to 
any file. It is the responsibility of the task to enforce 
security and the responsibility of the system manager to insure 
the integrity of such tasks. A separate utility is provided to 
assign the security bypass attribute to a task. Access to this 
utility can be controlled by securing the proc and the program 
file in which it is installed. 



- 10 - 



DNOS FILE SECURITY 



DOCUMENTATION 



The use of file security will be carefully documented in a 
new manual entitled DNOS Security Manager^s Guide . It will 
include a thorough description of the role and responsibilities 
of the security manager. The DNOS System Command Interpreter 
Reference Manual will describe the security implications if 
any, in the descriptions of the individual commands. 
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1. Interprocess Cbramunication Mechanisms 



There are many programming applications that require the use of 

synchronization or communication between processes. The Texas Instruments 

990 operating systems provide several mechanisms by which processes can 
exchange signals or messages. These mechanisms are: 

* Shared procedures (DNOS and DXIO) 

* Intertask message queues (DNOS and DXIO) 

* Semaphores (DNOS) 

* Shared segments (DNOS) 

* Event Synchronization (DNOS) 

* Interprocess communication channels (DNOS) 

Shared procedures and segments suffer from the limitation that the 
communicating tasks themselves must coordinate their use of the shared 
data. Message queues have only a rudimentary synchronization capability 
and no access control other than a usage convention which is not enforced 
by the operating system. DNOS semaphores are used for synchronization, but 
only between tasks in the same job. Event synchronization is a global 
mechanism by which one task can signal another, provided the signalling 
task knows the run-time ID and the job ID of the task to be signalled. A 
message passing facility may be necessary for the signalling task to obtain 
the job and run-time identifiers. 

The interprocess communication (IPC) channel facility of DNOS is the 
most versatile of all of these mechanisms. It is a means of global 
communication between any two or more tasks in the system. Tasks exchange 
messages by reading and writing over IPC channels that are created by the 
system at the request of the user and exist Independently of the tasks 
using them. The IPC facility can be used for both message exchange and 
synchronization, and it provides access control by which channel creators 
and users can limit the availability of a channel. 

Every IPC channel has an owner task which is specified at the time the 
channel is created. Every message exchange is between the channel owner 
and some other task. Tasks communicate over an IPC channel by assigning 
logical unit numbers (LUNOs) to the channel and then using ordinary I/O 
supervisor calls to read and write the messages. As with other I/O 
supervisor calls, if a read or write to a channel cannot be processed 
immediately, i.e., if there is no matching channel request from another 
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task, the task issuing the read or write is optionally suspended until a 
matching channel request is issued. This allows synchronization between 
cooperating tasks. Furthermore, the use of I/O SVCs as the means of 
communication to channels means that the access control imposed on opens to 
files and devices is also imposed on open operations to channels. A task 
which successfully issues an open operation with exclusive write access to 
a channel is guaranteed to be the only requester task writing to the 
channel. 



2. Uses of IPC 
IPC channels can be used to implement several programming functions: 

* Task synchronization 

* Queue service 

* Intermediate processing of data 

* Sending and receiving messages 

When IPC is used for task synchronization, the existence of a message 
may be more important than the message contents. Tasks may require 
synchronization in order to regulate access to shared resources or to 
guarantee that a series of operations are performed in a certain order. 
Like other I/O operations, IPC operations can suspend the issuer until the 
request completes. If the initiated I/O bit is set in the I/O call block 
or if the request is initiated by the Initiate Event SVC, the issuing task 
will continue to execute and can determine whether the request has 
completed by using a Wait for any I/O SVC, a Wait on Event SVC, or simply 
checking the busy bit in the request block. Either way, the tasks have a 
way of determining whether a message has been exchanged and can synchronize 
their actions accordingly. 

IPC channels can also be used to implement queue servers. An IPC 
channel and a server task would be created for each provided service. 
Tasks would submit requests for service by writing to the IPC channel. The 
server task would read the requests from the channel and then process the 
requests. 

Because the principal means of channel communication is resource- 
independent I/O SVCs, tasks that perform resource-independent I/O to files 
or devices require little or no change to use channels as sources of input 
or destinations of output. It is possible to use IPC to implement 
filters — tasks that perform intermediate processing of data. A task that 
writes its output to a VDT or file could just as easily write the data to a 
channel. The task that reads the data from the channel could perform some 
additional processing on the data and then output the data to a VDT or a 
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file or even to another channel for further processing. Because channel 
I/O usually requires no disk access, using channels to pipeline data can 
speed processing time. 

There are two types of channels — symmetric and master-slave. 
Symmetric channels permit the use of resource-independent I/O SVCs to send 
messages between tasks. The channel interface of a symmetric channel owner 
is much the same as that of any other task, hence the name "symmetric". 
Symmetric channels are particularly useful for implementing filters. 

Master-slave channels provide a mechanism for simulating I/O. A non- 
owner task (a slave) performs resource-specific I/O to the channel. The 
owner task (master) receives the full supervisor call block of the SVC 
issued by the slave, including any data that is being written. The master 
processes the slave's I/O request much like a Device Service Routine or 
file server processes requests. The master then returns the call block to 
the system, including any data being returned to the task. The master's 
interface to the channel is very different from that of a slave. The slave 
task may not even need to know that the resource to which it is sending 
requests is actually a channel. The master uses a special set of channel 
interface commands to obtain the requester's call block and return it to 
the system. A more detailed description of symmetric and master-slave 
channels follows below. 



3. Accessing Symmetric Channels from Pascal 

There are two ways to perform I/O to channels from tasks written in TI 
Pascal. The task can either use the standard Pascal I/O functions or can 
issue the supervisor call directly using the SVC$ routine. Resource- 
independent I/O to symmetric channels from either an owner task or a non- 
owner task can be done with standard Pascal text file I/O functions. 

To use standard Pascal I/O to access a channel, a file variable of 
type TEXT should be defined. The file variable is then associated with the 
channel. This can be done with the SET$ACNM function, which associates a 
file variable with a pathname, or the SETLUNO function, which associates a 
file variable with a LUNO. Either of the pre-defined text files, INPUT or 
OUTPUT, may be used to access a channel. The synonym INPUT or OUTPUT must 
have been externally defined as the channel name. 

The following Pascal functions can be used to access the channel: 

* RESET(F) — Open text file (channel) F for input. 

* REWRITE(F) — Open text file (channel) F for output. 

* READLN(F) — Read the next record from file F. This operation 
performs a read to the channel. 
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* WRITELN(F) — Write the current contents of the line buffer to 
file F, This operation writes the buffer to the channel. 

* EOF(F) — Result is TRUE if the last READLN matched to a Write EOF 
operation. 

Other Pascal functions that can be issued to a text file are listed in the 
Tl Pascal Programmer's Guide. The READ and WRITE functions to a symmetric 
channel w'iTl not cause ~T read or write SVC to be issued to the channel. 
READ and WRITE only read from and write to a local line buffer. For the 
read or write to actually go to the channel, a READLN or WRITELN must be 
issued. Task termination causes the LUNO to the channel to be closed. 
Before issuing the close, the Pascal task will issue a Write EOF. This 
will match a read operation to the channel performed by another task and 
cause an EOF function performed by the other task to return the value TRUE. 

An example program that implements a filter is shown in Figure 1. The 
program accepts input from a resource- independent source, processes the 
input, and then outputs the data to a resource-independent destination* In 
this case, the default text files INPUT and OUTPUT are used. Either of the 
two files or both of them could be channels. This task could either be a 
channel owner or a non-owner. Instead of using the default input and 
output files, the task could have obtained the filenames from a synonym, 
which could either be already known to the task or could have been passed 
in as a parameter. 



4. Accessing Master-Slave Channels from Pascal 

I/O operations from slave tasks can either be issued by standard 
Pascal I/O routines or by the SVG$ routine. Since master-slave channels 
are intended to simulate I/O, a slave task may perform any kind of I/O 
operation to the channel, provided that the type of I/O is compatible with 
the resource type of the channel and that the channel master is written to 
handle that type of I/O. The channel interface of a master of a master- 
slave channel must be written using direct supervisor calls with SVC$. The 
special I/O operations used by the channel master to obtain and return call 
blocks are not supported by intrinsic Pascal I/O functions. The master's 
channel interface is explained below. 
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5. Creating and Using IPC Channels 



5.1 Creating and Deleting Channels 

When a channel is created, a disk-resident channel descriptor is 
built. The channel has a pathname and is located in a directory like a 
file. Rebooting the system does not delete the channel. The channel has 
no memory resident representation until a task assigns a LUNO to it. A 
channel can either be created by a task by issuing the Create Channel SVC 
(I/O subopcode >9D) or from SCI by issuing the Create IPC Channel (CIC) 
command. In either case, the following information must be provided: 

* Channel name, which must be a valid pathname. 

* Program file which contains the owner task. The program file must 
be in the same directory as the channel. If the channel name is 
".A.B.C", the program file must be in the directory ".A.B". 

* Installed ID or name of the owner task in the program file. 

* Channel type — symmetric or master-slave. 

* Channel scope — global, job- local, or task- local. 

* Channel message length — the maximum number of bytes that can be 
transferred in one message. 

* Channel type — shared or non-shared. 

* Default resource type (master-slave only) 

Channels can be deleted from a task by the Delete Channel SVC (I/O 
subopcode >9E) or from SCI by the Delete IPC Channel (DIC) command. 

IPC provides several options by which users can tailor a channel to 
meet their particular needs. A channel can either be symmetric or master- 
slave, can be available at a system-wide (global) level, a job-local level, 
or a task- local level, and can either be shared or non-shared. Each of 
these options is explained in the following sections and guidelines for 
choosing the type of channel are presented. 
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5.2 Symmetric Channels 

Symmetric channels are suitable for applications that require only a 
simple exchange of data buffers or messages. If the application requires 
more complex I/O operations, as is frequently the case when I/O to a device 
or file is being simulated by I/O to a channel, the channel will have to be 
master-slave. If the application requires that the channel be multiplexed 
(used simultaneously by more than one task) and that the data exchange 
between the owner and requester be bi-directional, master-slave channels 
will be necessary. The reason for this will become clearer in the 
following discussion of shared and non-shared channels. 

Every message transfer on a symmetric channel is either to or from the 
owner task. Each task opens the channel, performs read or write operations 
to the channel to accomplish the exchange of data, and then closes the 
channel. Each read operation to the channel must be matched by a write 
operation from another task. The actual data which is exchanged is the 
contents of the write buffer which is transferred to the read buffer of the 
task performing the read operation. In Figure 2, the supervisor call 
blocks for channel operations from two tasks are shown. The message 
written to the channel by task B is read by task A. 

The operations allowed to symmetric channels are the same for both 
owners and requesters. The allowed operations are: 



00 


Open 


01 


Close 


05 


Read device status 


09 


Symmetric read 


OB 


Symmetric write 


OD 


Write EOF 



The following sub-opcodes are allowed and perform operations identical to 
those shown: 

Identical to 



Sub-opcode 


Operation 


OA 


Read direct 


OC 


Write direct 


02 


Close, write EOF 


03 


Open Rewind 


04 


Close and unload 



Symmetric read 

Symmetric write 

Close 

Open 

Close 

Open operations Issued from requester tasks are queued until the owner task 
has opened the channel. Once the channel has been opened by the owner and 
one or more requesters, message transfer can take place. Symmetric reads 
and writes that cannot be processed immediately because there is no 
matching operation are queued. The channel requests are processed in a 
first come-first served manner. The next owner request is matched to the 
next requester request. If the operations are of different type (read- 
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write), the message transfer is performed. If the operations are of like 
type (read-read or write-write) , both the owner and requester operations 
are returned with an error. A write EOF request matches a read, setting 
the EOF flag in the read call block and zeroing the actual read count. 

One important difference between the owner's channel interface and 
that of the requester is that an owner may only have one operation 
outstanding to a particular channel at a time. If the owner initiates a 
request to the channel, the owner will have to wait until the first request 
completes before issuing another request. If the owner issues a second 
request before the first completes, the second request will receive an 
error. 



5.3 Master-Slave Channels 

Resource-specific channel I/O is performed by master-slave channels. 
In symmetric channel I/O, the actual data transferred between communicating 
tasks is the contents of the data buffer of the symmetric write. In 
master-slave channel I/O, the actual data transferred is the entire 
requester call block. Unlike symmetric channel I/O, where each owner 
operation matches one requester operation, master-slave channel I/O 
requires two owner operations to match each slave operation. One owner 
operation reads in the requester call block; the second owner operation 
writes the call block back to the requester. The returned call block will 
contain any returned data or error codes. All requester I/O operations to 
the channel, including opens and closes, are passed to the channel master. 
I/O utility operations, such as Assign and Release LUNO, and Abort I/O SVCs 

r.An nnl- 1 r\na 1 1 -u Kq noocm^l *-^ «-U^ _^»<-^» ^^ ii nm a. s __. i__ 

-J— _^ ^^^^^^j „,_ l^doocia K.\j uiic 1UCIOI.C1. dO WCXJ.. Xlie UpUJ-Uli CclU OH 

specified when the channel is created. 

In symmetric channel communication, owners and requesters are allowed 
the same set of limited operations. In master-slave communication, slave 
tasks can issue any I/O command to the channel. IPC supports the full set 
of resource-specific I/O to master-slave channels. When a master-slave 
channel is created, a channel resource type is specified. If the resource 
type is a file type, file I/O operations to the channel are allowed. If 
the resource type is a device type, device-specific operations to the 
channel are allowed. If the resource type is channel, only resource- 
independent I/O to the channel is allowed. 

The operation used by a channel master to read a requester call block 
is the Master Read. The data buffer of the master read operation will 
contain five words of header information followed by the full requester 
call block after the master read operation completes. The call block is 
written back to the channel with a Master Write operation. The data buffer 
of the master write operation contains the header information (unchanged), 
the requester call block, and any data being returned to the slave task. 
The master may only have one master read operation outstanding at any one 

- 8 - 



time. However, the master may do any number of master write operations 
while a master read is pending. 

Figure 3 shows a requester read operation before the supervisor call 
is issued. After the requester has issued the request and the master has 
issued the master read, the master read call block and its data buffer will 
appear as shown on the left side of Figure 3. Figure 4 shows the call 
block of the subsequent master write. The channel master has updated the 
actual character count in the requester call block and is returning data. 
The left side of Figure 4 shows the requester call block and data buffer 
after the master write completes. 

It was stated in the previous section that a symmetric channel cannot 
be simultaneously multiplexed and bi-directional. It may not be apparent 
how a master-slave channel can serve this function either, since a master 
cannot independently send a message to a slave task. A master can only 
process and return slave operations. One way to achieve this message 
exchange is by using a write with reply operation. The resource type of 
the channel would have to be VDT, since the write with reply operation is 
only meaningful for terminals. The requester does a write with reply to 
the channel and the master returns a message to the requester in the reply 
block. The program in Figure 5 implements a channel master which serves a 
queue of requests from various slave tasks and returns information to each 
slave task that issues a request. 



5.4 Channel Scope 

IPC channels are either global, job- local or task- local. The scope of 
a channel determines whether a channel and channel owner are replicatable 
and whether an assign to the channel results in the channel owner being bid 
automatically. The characteristics of each of these types is as follows: 

* Global — There is only one instance of a global channel at a time 
and it can be accessed by any task in the system. The channel 
owner must be the first task to assign a LUNO to a global channel. 

* Job-Local — A job-local channel may be replicated— one instance 
per job. The channel is accessible to any task in the job. 
Either the owner task or another task may be the first to assign a 
LUNO to the channel. If a task other than the owner is the first 
task to assign a LUNO to the channel, the owner task will be 
automatically bid. 

* Task-Local — A task- local channel and its owner task are 
replicated for each task that assigns a LUNO to the channel. Each 
non-owner task that assigns a LUNO to the channel gets its own 
instance of the channel. The owner task is automatically bid by 
the Assign LUNO. A task-local channel owner may not be bid 
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directly. 

If the two tasks that need to communicate can be anywhere in the 
system, or if the channel owner is not replicatable, the channel will have 
to be global. If the communicating tasks will always be in the same job or 
if they can be replicated in many jobs, the channel should be job- local or 
task-local. A task-local channel is appropriate if the function performed 
by the channel owner can safely be performed simultaneously by more than 
one instance of the channel owner. Task local channel owners are 
replicated for every LUNO assigned to them. If the channel owner is 
controlling a resource that is available to the entire job, the channel 
should be job- local so that only one task is accessing the resource at a 
time. 



5.5 Channel Type — Shared or Non-Shared 

Before discussing the difference between shared and non-shared 
channels, a discussion of channel states is in order. A channel is always 
in one of three states relative to a task which has assigned a LUNO to it. 

* Closed — The task must open the channel before performing reads 
or writes to the channel. 

* Open — The task may issue reads or writes to the channel. 

* Dormant — The task must issue a close, and then may reopen the 
channel. If there are any outstanding operations to the channel 
at the time the channel becomes dorniant- the c^erations V7ill be 
returned with an error. Any subsequent operations (except a 
close) will be returned with an error. The dormant state only 
applies to symmetric channels. 

For all types of channels, open operations performed by non-owners are 
queued until the channel owner's open has completed. An owner close always 
puts the channel into the dormant state relative to all requesters. The 
requesters must close the channel and then may reopen the channel. 

Shared and non-shared channels have the following characteristics: 

* Shared — A shared channel may be accessed simultaneously by any 
number of requesters. A close issued by a requester does not 
change the state of the channel relative to the owner. 



* 



Non- Shared — A non-shared channel may only be opened by one non- 
owner task at a time. This is true regardless of the access 
privileges requested by the requester open. If a second requester 
issues an open to a non-shared channel before the first requester 
closes its LUNO, the second open request will receive an error. 
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After a requester task has closed its LUNO to the channel, that 
task or any other requester task may open a LUNO to the channel, 
A requester close operation causes a symmetric channel owner to 
become dormant relative to the channel owner, i.e., any 
outstanding or subsequent operations (except a close) will be 
returned with an error. The owner should close the channel and 
reopen it. Another data exchange may now take place. 

The unlimited accessibility of shared channels is usually acceptable 
for master-slave channels because the output of a master write always 
returns to the slave task that originally performed the request to the 
channel. The header information provided to the master in the data buffer 
of the master read allows the master to differentiate between requesting 
tasks. Furthermore, since master-slave channels are usually used for the 
purpose of simulating I/O, the standard access control imposed by the 
operating system on LUNO opens is the most useful means of limiting access 
to a particular channel. 

Shared channels are not sufficient for many symmetric channel 
applications. An owner of a shared symmetric channel has no way to direct 
a message to a particular task. The owner operation to the channel will be 
matched to whatever requester request happens to be next on the queue. 
Non-shared symmetric channels are intended for applications requiring an 
extended message exchange between two tasks. Once a requester has 
successfully opened the channel, the owner is guaranteed that there is only 
one requester sending and receiving data. The owner will also know when a 
session with a particular requester has ended because of the error code 
received on an owner operation after the requester has closed its LUNO to 
the channel. 

An example of a bi-directional message exchange using a non-shared 
symmetric channel is shown in Figure 6. 

The non-shared attribute is much less useful for master-slave 
channels, but it can be used to limit access to the channel to one slave 
task at a time. A master-slave channel does not become dormant to the 
master in the case of a requester close. The master knows that a session 
has ended when a requester close is master read. 



6. Executing and Debugging Tasks That Use IPC Channels 

Most Pascal tasks that use channels can be bid from SCI by the Execute 
Pascal Task (XPT) command or by the SCI primitives, BID, DBID and QBID. 
Synonyms which specify the input and output of the task can be defined. 
Task- local channels owners must be handled differently. Task- local channel 
owners will never be bid by SCI, but will instead be bid by the system as a 
result of an Assign LUNO to the channel. Therefore, the input and output 
access names cannot be obtained from synonyms. The access names could be 
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specified directly in the task code. This may be acceptable in the case of 
the channel name, since it won't change for the channel owner. Logical 
names could also be used to specify the input or output. The value of the 
logical name can be obtained from a Map Name SVC. The input and output 
access names could also be read from a known file. 

Debugging programs that use IPC channels presents some special 
problems. If there is more than one terminal available for debugging and 
if the scope of the channel allows both tasks to be bid from SCI, debugging 
programs that use IPC should not be different than debugging any other 
program. The owner task is bid in debug mode from one terminal and a non- 
owner task is bid in debug mode from another terminal. Both tasks can be 
controlled by the debugger. If the channel is job- local, the owner task 
should be bid first and both stations should be connected into the same 
job, through the reconnect capability. 

If the channel is task-local, the owner task cannot be bid from SCI. 
Even for global and job- local channels, only one of the communicating tasks 
can be bid in debug mode if there is only one terminal. Tasks bid in debug 
mode from SCI are background tasks, and there can only be one background 
task per station. If the channel is task or job- local, the owner task can 
be bid by assigning a LUNO to the channel. If the channel is global, one 
of the communicating tasks must be bid with a Bid Task SVC. 

There are several ways to get a task which was not bid in debug mode 
into a state where it can be controlled and debugged. First, the task must 
be put into an unconditionally suspended state (state 6). This can be done 
by issuing a Suspend Task SVC (SVC 6) from the task which is to be debugged 
or by using the l^odify Program Image (MPI) SCI command to temporarily 
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15,15 02FCF) before bidding the task. Once the task is in state 6, the 
Pascal debug commands can be used to set breakpoints in the task, resume 
execution of the task, and inspect the stack and memory. Two or more tasks 
can be controlled from the same station. Each of the debug commands 
requests a run ID of the particular task to be inspected. The run ID for 
each task can be obtained by a Show Task Status (STS) command. The Execute 
Debugger (XD) command and all of the other debug commands that XD enables 
(Set Simulated Breakpoint, for example) will only work for one task at a 
station. Some commands that can be used for more than one task at a 
station are: Show Panel (SP), Show Pascal Stack (SPS), List Pascal Stack 
(LPS), Assign Breakpoint (AB), Assign Breakpoint - Pascal (ABP), Proceed 
from Breakpoint (PB), Proceed from Breakpoint - Pascal (PBP) , Modify Memory 
(MM), and Modify Internal Registers (MIR). 

One very useful technique to debug tasks that use channel I/O is to 
set a breakpoint before and after the SVC$ routine. The only parameter to 
the SVC$ routine is a pointer to the supervisor call block about to be 
issued. By examining the call block before and after the SVC$ routine, 
problems related to the channel interface can be found. 
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One problem conimonly encountered while debugging tasks that use IPC 
channels is finding a task hanging in state 9 (waiting on I/O). When the 
task is in this state, Show Pascal Stack and Show Panel will not work. 
This makes it difficult for the programmer to determine what caused the 
hang. The problem of tasks hanging in state 9 is usually caused by an 
error in synchronization between two tasks. One task is expecting a 
message and the other task is no longer communicating to the channel. One 
way to debug this situation is to print a copy of the SVC block to a 
terminal or file before the SVC is issued. If a hang occurs, the last SVC 
block will then be available. 



7 . Summary 

IPC channels can be used in most applications requiring communication 
between tasks. More detailed information regarding the use of Pascal I/O 
and IPC channels can be found in the Model 990 Com puter DNOS TI Pascal 
Programmer's Guide and the DNOS Superv isor Call Reference Manual. 
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PROGRAM FILTER; 

(* READ DATA FROM STANDARD INPUT, PROCESS DATA, AND WRITE 

TO STANDARD OUTPUT *) 
VAR PHRASE: PACKED ARRAY[1..50] OF CHAR; 
BEGIN 

RE SET ( INPUT) ; 
WHILE NOT EOF( INPUT) DO 
BEGIN 

READ( INPUT, PHRASE: 50); 
RE ADLN( INPUT); 

(* PERFORM INTERMEDIATE PROCESSING HERE *) 
WRITELN(OUTPUT,PHRASE:50) 
END 
END. 



FIGURE 1 — SAMPL E PASC AL SYMME TRIC CHMNEL TASK PROGRAM 
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FIGURE 2 — SYMMETRIC CHANNEL MESSAGE EXCHANGE 
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HEADER 


OF 
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00 
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SLAVE'S CALL BLOCK BEFORE SUPERVISOR CALL 



MASTER'S CALL BLOCK AFTER MASTER READ 



FIGURE 3 — MASTER- SLAVE DATA EXCHANGE 
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MASTER TASK 



SLAVE TASK 



OPCODE, ERROR 

SUB0PC0DE,LUN0 

FLAGS 

DATA BUFFER ADDR 

INPUT CHAR COUNT 

ACTUAL CHAR COUNT 





00 


00 




IB 
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-> 
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OF 
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B 
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00 


00 
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-> 


ABCDEF 



SLAVE'S CALL BLOCK AFTER MASTER WRITE 



MASTER'S CALL BLOCK AFTER MASTER WRITE 



FIGURE 4 — MASTER-SLAVE DATA EXCHANGE 
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PROGRAM MASTER; 

(* MASTER READ A REQUEST. IF IT IS A WRITE WITH REPLY, READ THE 
INCOMING DATA AND RETURN A REPLY. THIS PROGRAM ASSUMES THAT 
A SHARED JOB-LOCAL OR GLOBAL MASTER- SLAVE CHANNEL WITH THE 



PATHNAME '.CHAN' HAS BEEN CREATED. 
DEFAULT RESOURCE TYPE OF VDT. 



THE CHANNEL MUST HAVE A 



(* DEFINE OPERATION CODES *) 



*) 

CONST P_OPEN = 0; P_CLOSE = 1; 

P_ALUNO = #91; P_WRITE = #0B; 
MASTER_READ = #19; MSTER_WRITE = #1B; 

INVALID_CALL_ERR =1; (* DEFINE ERROR CODES *) 

TYPE BYTE = 0..#FF; 

BUFFER = PACKED ARRAY[1..50] OF CHAR; (* BUFFER DEFINITION*) 

BUFPTR = @BUFFER; 

RPY = PACKED RECORD (* REPLY BLOCK DEFINITION *) 

RPYBUF: BUFPTR; 

RPYICC: INTEGER; 

RPYOCC: INTEGER 

END; 
RPYPTR = (aRPY; 
ACNM = PACKED RECORD 

CH: PACKED ARRAY [0..5] OF CHAR 

END; 
PNAPTR = @ACNM; 
SVCBLK = PACKED RECORD 

SOC,ERR: BYTE; 

OC,LUN: BYTE; 

SFLAG: INTEGER; 



(* PATHNAME DEFINITION *) 



(* SVC BLOCK DEFINITION *) 



DBA: 



BUFPTR; 





ICC: 


INTEGER; 




OCC: 


INTEGER; 




RPY: 


RPYPTR; 




RESl: 


INTEGER; 




FLG: 


INTEGER; 




RES2,RES3: 


INTEGER; 




PNA: 


PNAPTR; 




REST: 


PACKED ARRAY [1.. 6] OF INTEGER 




END; 




SVCPTR 


= (asVCBLK; 


(* MASTER READ BUFFER DEFIN 


MRB 


= PACKED RECORD 




HEADER: 


PACKED ARRAY [1.. 5] OF INTEGER; 




REQUEST : 


SVCBLK; 




DATABUF: 


PACKED ARRAY [1.. 70] OF BYTE 




END; 




MRBPTR 


= (SMRB; 





FIGURE 5 — MASTER-SLAVE OWNER EXAMPLE PROGRAM 
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VAR GALLBLK 

PATH 

MRBP 

NAME 

I 

MS GLEN 

MSGPTR 

RPYP 



SVCPTR; 
PNAPTR; 
MRBPTR; 

PACKED ARRAY [1.. 5] OF CHAR; 
INTEGER; 
INTEGER; 
BUFPTR; 
RPYPTR; 

PROCEDURE SVC $ ( P : SVCPTR) ; EXTERNAL ; 
PROCEDURE ERROR PROC; 
BEGIN 

(* ERROR PROCESSING *) 
END; 
(* SET UP AND ISSUE MASTER WRITE *) 
PROCEDURE MWRITE( P ; SVCPTR) ; 
BEGIN 

P@.OC := MASTER_WRITE; 
P@.OCC := 100; 
P^.SFLAG := 0; 
SVC$(P); 

IF Pia.ERR <> THEN ERROR_PROC; 
END; 
(* BEGIN MAIN PROGRAM *) 
BEGIN 

NEW(CALLBLK); (* GET SVC BLOCK *) 

NEW(PATH); 

NEW(MRBP); 

NAME :='. CHAN'; 

PATH(a.CH[0]:= '#0A'; 

FOR I:=l TO 5 DO 

PATH(a.CH[I] :=NAME[I]; 
WITH CALLBLK(a DO (* BUILD ASSIGN LUNO *) 
BEGIN 
SOC:=0; 
ERR:=0; 
0C:= P_ALUNO; 

FLG:=#0400; (* AUTOGENERATE LUNO *) 
PNA:=PATH 
END; 
SVC$(CALLBLK); 

IF CALLBLK(a.ERR <> THEN ERROR_PROC; 
CALLBLK@.OC:= P_OPEN; (* OPEN LUNO *) 
CALLBLK(a.SFLAG := 0; 
SVC$(CALLBLK); 
IF CALLBLK@.ERR <> THEN ERROR PROC; 



FIGURE 5 — CONTINUED 
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WHILE (TRUE) DO (* DO FOREVER *) 
BEGIN 
WITH CALLBLK(a DO BEGIN 

OC := MASTER_READ; (* SET AND EXECUTE MASTER READ *) 
ICC := 100; 
SFLAG := 0; 
DBA : = MRBP : : BUFPTR 
END; 
SVC$(CALLBLK); 

IF CALLBLK@.ERR <> THEN ERROR_PROC; 

(* PROCESS REQUESTER CALL BLOCK. MASTER WRITE OPENS AND 
IMMEDIATELY. PROCESS WRITE BUFFER OF WRITE WITH REPLY 
AND PROVIDE A REPLY. IF THE REQUEST IS NOT AN OPEN, 
CLOSE OR WRITE, RETURN IT WITH AN ERROR. *) 
CASE. MRBP@. REQUEST. OC OF 
P_OPEN : MWRITE ( CALLBLK) ; 
P_CLOSE : MWRITE ( CALLBLK) ; 
P_WRITE: BEGIN 

MSGLEN := MRBP@.REQUEST.OCC; 

(* MRB ADDRESSES ARE BYTE OFFSETS FROM BEGINNING OF MRB*) 
MSGPTR: : INTEGER: =MRBP(a . REQUEST. DBA: : INTEGER 

+ MRBP : : INTEGER; 
(* ***** REQUESTER MESSAGE CAN BE PROCESSED HERE. MSGPTR 
IS A POINTER TO THE INPUT BUFFER. MSGLEN IS THE 
LENGTH OF THE MESSAGE. *) 
RPYP : : INTEGER : =MRBP(a . REQUEST . RPY : : INTEGER 
+ MRBP:: INTEGER; 
(* ***** RETURN REPLY HERE. RPYP IS THE POINTER TO THE REPLY 
BLOCK IN THE MRB. THE REPLY BLOCK CONTAINS A BUFFER 
POINTER (WHICH WILL HAVE TO BE ASSIGNED HERE, A 
MAXIMUM INPUT COUNT AND AN ACTUAL READ COUNT (WHICH 
WILL ALSO HAVE TO ASSIGNED HERE). FOR CONVENIENCE, 
USE THE SAME BUFFER THAT WAS USED FOR THE INPUT 
MESSAGE TO STORE THE REPLY. THERE MSGPTR POINTS TO 
THE OUTPUT MESSAGE BUFFER. *) 
RPYP(a.RPYBUF:= MRBP@. REQUEST. DBA; 

RPYP(a.RPYOCC:= 10; (* OR WHATEVER THE LENGTH IS *) 
MWRITE (CALLBLK) 
END 
OTHERWISE BEGIN 

CALLBLK@.ERR := INVALID CALL; 
MWRITE( CALLBLK) 
END 
END 
END 
END. 

FIGURE 5 — CONTINUED 
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TIME OWNER TASK ACTIONS 



REQUESTER TASK ACTIONS 



OPEN CHANNEL (task waits) 

OPEN CHANNEL (open completes) 

READ (task waits) 

WRITE - MSG: A (Read completes, msg: A) 

READ (task waits) 

(read completes , msg: B) WRITE - MSG: B 

WRITE - MSG: C (task waits) 

(write completes) READ (completes, msg: C) 

READ (task waits) 

(read completes with error) CLOSE 
(channel is dormant to owner) 

CLOSE 

(channel is closed to owner) 

OPEN 

(channel is open to owner) 



FIGURE 6 — NON-SHARED SYMMETRIC CHANNEL MESSAGE EXCHANGE 
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TWO NEW UTILITIES FOR DATA BACKUP 
by 
Harold Wilensky 

1 Introduction - The Tortoise and the Hare 

I am sure that you remember the story of the Tortoise and 
the Hare. One of the lessons that can be learned from that story 
is that faster is not necessarily better. On that particular day 
and in those particular circumstances the faster animal did not 
win the race. I would like for you to keep that lesson in mind 
as I talk about some new data backup utilities currently in 
development. They are faster than the others that we support and 
for many installations that is the overriding concern. However, 
because some limitations have been placed on these utilities to 
achieve greater speed, they will probably not be perfect for 
everyone. 



2 Definitions 

Before we get into the details of these utilities I would 
like to define four terms that will be used quite often and 
sometimes cause confusion. 

1. Backup - A sequential representation of a directory 
structure, e.g. the output of Backup Directory 

2. Copy - A duplicate of a directory structure, e.g. the 
output of CVD or CD. 

3. Disk Compression - Avoidance of secondary allocations 
and a contiguous packing of data 

4. File Compression - Making allocated but unused space 
available 
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3 Our goals and how we achieve them 

For some time now we have been receiving input from our 
customers concerning the functionality of the data backup 
utilities currently supported. After consulting with some of our 
customers, the Customer Support Line, our marketing personnel, 
and the TIMIX Systems Committee we developed some goals that 
should be met by any new data backup utilities: 

1. Speed - This was the overwhelming concern. As larger 
disks became available speed became an overriding 
concern. It is unreasonable to expect someone to spend 
a half day to copy a disk. The way to increase speed 
is to maximize parallelism between CPU activity and I/O 
and overlap I/O as much as possible. To achieve much 
greater speed, some trade-offs have to be made with 
regard to flexibility. These trade-offs exact a 
certain price. That price is to disallow any 
selectivity options such as backup by date or "copy 
this directory but exclude file X." This is the sort 
of trade-off I had in mind when I mentioned the story 
of the Tortoise and the Hare. 

2. The utility must do its own verification if requested. 
This is very highly recommended. When copying between 
disks or backing up to disks, the verification is 
performed in parallel with data transfer. This is 
faster than making a separate pass. 

3. All media supported by the DS990 and Business System 
Series products must be supported. This includes non- 
error free media, error correcting and bad track 
avoidance disks. Many of the newer disk types use 
technologies that are very sensitive to disk surface 
abnormalities. These disks cannot be guaranteed to be 
error-free; therefore, a physical, track-by-track copy 
such as DCOPY (which is quite fast) won't work. 

4. User friendliness - Keep the user informed about what 
is happening and give informative error messages. As 
much as possible the user interface should be through 
SCI. If a series of copies or backups (analogous to 
multiple runs of DCOPY or CVD) is needed, all 
information about the copy or backup should be 

■«-,-.^.i^n 1-/^/4 «-!-. v»/-kiir»1-> cr'T TK-1 o T.^l-\1■t'\ A -mr/wT-i Aa an i ni- ayf afa 

1. C:v£U<=:0 U<=U. Ulll. X^CL^Ll k/VJt.. ^li.ju<^ n\j\j.j.\j. ^ M. \^ n j.\j.\^ <^«.i ^«.x».N,». ^■w.v.'w 

compatable with the rest of the DXIO or DNOS system* 
The user should be kept informed of the progress while 
the utility is active and receive informative messages 
when error conditions are encountered. 
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5. Single fixed/ removable drive systems - The utility must 
be useable on systems in which there is a single disk 
drive, one of whose platters is fixed, e.g. the 
CD1400. This implies that the utility must be able to 
run without a system disk. 

6. System disks created by a copy must be immediately 
bootable. 

7. One should be able to copy between different kinds of 
disks regardless of sector size, ADU size or physical 
record length. 

8. Disk and file compression should be performed. In the 
copy process files should be compressed to the end of 
used space when possible, secondary allocations should 
be minimized, and program files should be compressed. 

How are we meeting these goals? We are developing two new 
utilities that will compare to the directory utilities(BD, CD, 
etc.) in much the same way that the Hare compared to the 
Tortoise: They will be much faster and in many ways more 
attractive; but keep in mind that they may not be perfect for 
every environment. These two new utilities will be released with 
the next releases of DXIO and DNOS. They are Copy Volume(CV) and 
Backup Directory to Device(BDD). The information I will present 
about these two utilities is subject to change because they are 
still under development. 



4 CV - Copy Volume 

Copy Volume copies an entire disk volume to another disk 
volume regardless of sector size, physical record size, or any 
other disk characteristic. If the source disk has more data on 
it than the destination disk is capable of containing, then CV 
will copy as much as possible. CV performs optional data 
verification in parallel with its other activities. We highly 
recommend that you request verification. When copying to a disk 
with a different physical record length than the source, you may 
request that physical record length conversion take place for 
sequential and/or relative record files. This makes much more 
efficient use of the destination disk. An optimal physical 
record length is calculated by CV. CV performs both disk and 
file compression on most files. The exceptions are any file that 
is created non-expandable, Key Indexed Files, and Program Files. 
KIFs are not compressed at all. Program files are always 
compressed to the extent that unused space at the end of the file 
is released. "Holes" created in a program file by previously 
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deleted tasks are recovered in many instances. CV has the 
ability to perform a series of copies in much the same way as 
DCOPY and CVD. CV, however, requests all of the information 
about the copy (or copies) to be performed through SCI. Once the 
copy is under way the user with a VDT is kept informed about the 
progress of the copy. CV also has the ability to run without a 
system disk so that systems with a single fixed/ removable drive 
can copy data volumes. CV does not support any selectivity 
options such as copy by date. 



5 BDD - Backup Directory to Device 

Backup Directory to Device backs up any one directory and 
all of its files and sub-directories to disk or tape. Data 
backed up with BDD is restorable with the Resore Directory 
^-command. BDD performs optional verification. When backing up to 
a disk(or multiple disks) the verification is performed in 
parallel with other activity. When backing up to a tape(or 
multiple tapes) the verification takes place on a second pass of 
the data. BDD performs the same kind of file compression as CV. 
BDD has the same user interface as CV. Like CV it keeps you 
informed of its progress. It also has the ability to run without 
a system disk. BDD does not support any selectivity options. 



6 Technical Overview 

In the preceding discussion of CV and BDD much was made of 
their speed and lack of flexibility. This technical discussion 
of their implementations should give you some insight concerning 
those issues. Before going into that discussion a little 
background is necessary. 

Background . As you know the DXIO and DNOS file structure 
consists of disk volumes which contain one or more directories. 
Each directory may contain zero or more files and zero or more 
directories. A directory is really a special case of a relative 
record file. Each record is one sector in length and contains a 
File Descriptor Record(FDR), Alias Descriptor Record(ADR) or Key 
Indexed File Descriptor Record(KDR). For DNOS a Channel 
Descriptor Record(CDR) is also possible. The records in a 
directory must be contiguous. An FDR contains information about 
a particular file or directory. That information includes the 
starting disk address of the file or directory, its size and disk 
allocation information. For the purpose of this discussion we 
will ignore ADRs, KDRs and CDRs since they have little impact on 
the algorithm. The following diagram should help to explain this 
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file structure. 

H ^ 

Consider the following directory structure: 

Dl 

I 

/ \ 

/ \ 

D2 Fl 

I 

/ \ 

/ \ 

F2 F3 

Its directories would look like this: 
Dl(directory) 



I FDR I 

I fori D2(directory) 
|F1 I 

H + 

II II 

I I H + 

I I IFDRI 

H + I for I 

jFDRI |F2 I 

I for I H + 

|D2 I IFDRI 

+ H I for I 

II |F3 I 

H + 

I I 



+ , 

Figure 1 Sample Directory and File Structure 
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Copy Volume. The implementation of GV is based on the idea that 
minimizing the number of FDR accesses can buy a great deal of 
speed. Specifically, the CV algorithm reads and writes several 
FDRs at one time. This minimizes I/O operations because FDRs 
within a given directory exist contiguously on the disk. CV 
keeps the FDRs in an internal buffer and uses the information 
contained in the FDR to determine the absolute disk address of 
each allocation of a source file. CV then reads the source data 
into one of its data buffers. If the entire file will not fit, 
it reads as much as possible* If more than one file will fit 
then as many files as will fit are read into the buffer. It is 
also possible for the last part of one file and the first part of 
another file to be in the buffer at any give time. The data is 
then written to the destination disk. When all of the FDRs in 
the FDR buffer have been processed, the FDR buffer is written to 
the destination disk in an area previously allocated for the 
directory that these FDRs belong to. CV uses an internal stack 
of directory information to keep its place in the directory 
hierarchy. 

CV uses five buffers for I/O: Two input, two output and one 
verify buffer. Whenever possible, the reading of source data is 
done in parallel with the writing to the destination disk of 
previoulsy read data. Verification, which consists of a read 
from the destination disk into the verify buffer and a comparison 
of that data with data in the read buffer takes place in parallel 
with other activity. 

All I/O is done using direct disk I/O which bypasses the 
File Manager. This allows the CV program to calculate its own 
absolute disk addresses and thereby minimize disk head movement. 

It is the heavy parallelism and the ability to copy data 
from more than one file at a time that imposes the restrictions 
that have been mentioned. 

Backup Directory to Device . BDD creates as output sequential 
data that can be restored by Restore Directory(RD). In other 
words BDD creates the same output that Backup Directory(BD) 
creates. 

Like CV, BDD copies many FDRs at a time in order to minimze 
I/O. Unfortunately, BDD cannot gain as much I/O parallelism as 
CV because its output is sequential in nature. It does, however, 

nvprlao its CPU activitv with its I/O quite heavily. 

_. J- _.- , _ . ^ 

BDD maintains its place in the source directory hierarchy by 

the way it keeps FDRs in the FDR buffer. BDD's FDR buffer is a 

one to 23 level stack (because the longest pathname allowed by 

the system is 48 characters or 23 nodes) of queues. Each queue 
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entry is an FDR of a given directory. The length of the queues 
varies depending on the number of files in a given directory. 

BDD builds buffers that contain data formatted for the 
output media. Essentialy this is a sequential representation of 
the source directory hierarchy and consists of a file's FDR 
followed by the file. Like CV, data from more than one file may 
be in the output buffer at any given time. 

BDD uses direct disk I/O to read from the source disk. If 
the destination device is a disk then direct I/O is used to write 
the output data. 
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7 Differences between old and new 

The following tables describe the differences between the 
currently supported copy utilities and CV. 

Table 1 Speed and Flexibility Comparison of Copy Utilities 



-+ 



slow — CD CVD CV DCOPY — fast 

inflexible — DCOPY— CVD CV CD flexible 



-r—— — — ^— — — — — — —————— — — — . 

Table 2 Functional Comparison 


of Copy 


Utilities 




CD 


CVD 


CV 


DCOPY 


Keeps user informed Yes 


No 


Yes 


No 


of progress 









Copy sub-directory Yes No No No 

or file 

Copy to tape 

Copy between different 
disk types 

Self -Verification 

Requires that system 
disk remain installed 

Tolerates media errors 

Select particular files 
to be copied 

Performs disk and Yes Yes Yes No 

file compression 



No 


No 


No 


Yes 


Yes 


No 


Yes 


No 


No 


Yes 


Yes 


Yes 


Yes 


No 


No 


No 


Yes 


Yes 


Yes 


No 


Yes 


No 


No 


No 
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The following tables describe the differences between the 
currently supported backup utilities and BDD. 

Table 3 Speed and Flexibility Comparison of Backup Utilities 

+ + 

slow — BD BDD DCOPY —fast 

inflexible — DCOPY — BDD BD — — flexible 

+ + 

Table 4 Comparison of Backup Utilities 

BD BDD DCOPY 



Keeps user informed Yes Yes No 
of progress 

Backup sub-directory Yes Yes No 
or file 

Backup to multiple disk Yes Yes Yes 
or tape volumes 

Backup to sequential file Yes No No 

Restore to disk with Yes No No 
a sector size 
different from 
original source 

Restore to disk with Yes Yes No 
same sector size as 
original source but 
different ADU and 
physical record size 

Self -verification 

Requires that system 
disk remain installed 

Tolerates media errors 

Select particular files 
to be backed up 
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No 


Yes 


Yes 


Yes 


No 


No 


Yes 


Yes 


No 


Yes 


No 


No 



Performs disk and Yes Yes No 

file compression 
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8 Examples 



NOTE 

At this point some examples of CV and BDD 
will be presented. 
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NOTES 



TI-MIX 1983: OFERATIIiG SYSTE3fS PANEL Q&A 

The following questions were submitted to TI-MIX 1983 registration forms prior 
to March 15. TI has addressed these questions in writing below. Additional 
questions will be fielded during each panel discussion at TI-MIX 1983. 

Subnltted by Scott H. Jaffe, Sedata Systems, Inc., Seville, OB.i 

Would you consider adopting a standard DSR to support TI Personal and/or Home 
Computers as local/remote terminals under DXIO? 

TI Aosiier: There is an effort under way to support the TI Professional Computer 
as a VDT under DXIO via an emulation package written for the Professional 
Computer, The home computer should be able to function as a KSR into the TPD 
DSR under DXIO, but this has not been verified. There are no activities now 
under way for Home Computer access to DXIO as a VDT. 



I suggest adding memory file capability to DXIO. Fix the "offline" printer 
problem so that DXIO does not have to be re-IPLed to bring the printer back in 
service. 

TI Answer: It is unclear what you mean by "memory file." Both DXIO and DNOS 
provide a mechanism for sending data between tasks (ITC on DXIO and IPC or ITC 
on DNOS) . On DNOS this mechanism is supported via standard I/O calls through 
the IPC channel, and in both systems the data is buffered into memory. No 
provision is made for creating an entire "file" in memory. 

We have fixed all known printer restart problems in both DXIO 3.5 and DNOS 
1.1. If for some reason the printer "hangs" in an unknown hardware state 
(perhaps caused by static discharge) it can sometimes be cleared by doing direct 
CRU writes to re-enable it. Do an HO on the output device and turn the printer 
power off. Wait approximately 30 seconds to allow the capacitors in the printer 
to discharge. For serial printers write a hexadecimal value of 4600 to the CRU 
address associated with that device and for parallel printers write a 
hexadecimal FFFF to the CRU address. Turn the 

printer power on, put it online and do an RO command. If this does not work the 
interface will probably require an "I/O reset" which will require an IPL. See a 
member of the OS panel at TI-MIX to discuss your specific problems. 



Is there a systems package that will allow a 990 to address more than 64K at one 
time? 

TI Answer: The DNOS segmentation support allows memory resident segments to be 
exchanged under user control. Large applications have been developed using this 
feature. There are no other plans to directly support applications larger than 
64K on 990s. 



OPERATING SYSTEMS Q&A - PC. 1 



Sttbnitted by Bruce E. Mortfaa, Siepard Steel Co., Bartford, CT: 

Can we look forward to an enhancement which would limit the access of a user to 
a particular disk drive or a particular directory? 

TI Answer: DNOS 1.2 will provide a file access security subsystem. Individual 
files may be secured and secure disks will not be accessible on non-secure 
systems. 



^bodltted by Donald Mcdfaiuiy lioYa Systeas, Nashville, IN: 

When a task is suspended until the completion of I/O and the device involved 
(i.e. tape) encounters a device error (door not shut, etc.), how may the 
suspended task be cancelled? 

TI Answer: Device errors should be reported back to the task. If there are 
specific instances where this is not true, let the Customer Support Line know 
about it. 



Submitted by Rick Nebel, Southwest Baptist University, Bolivar, MO: 

Does TI have plans for new TI hardware and software products in the areas of 
multichannel MUXs (7 or 15 channels), new releases in remote terminals for 
multidropped and polling networks, and programming and operational aids such as 
program and/or report generators, etc.? 

TI Answer: There will be three new products announced at TI-MIX 1983 in this 
area. The CI-403 four-channel RS-232C multiplexor and the CI-404 four-channel 
fiber optic multiplexor join the CI-402 two channel interface to provide 
chassis-based Business Systems cost-effective FGC-compliant RS-232C ports. No 
effort is now under way for either 7 or 15 channel multiplexors. The 931 
terminal will also be announced at this time, providing a remote terminal 
capability via its RS-232C interface. This allows connection either via modems, 
or via third party statistical multiplexor devices. No specific multidrop or 
polling products are in our current plans. 



Submitted by David Teagarden, Moore Business Forms, Inc., Denton, TX: 

When is Query, or will it, have substring manipulation capabilities? 

TI Answer: Query already supports the ability to search character (CH) data for 
specified substrings. Possible enhancements would be to extend this capability 
to the character numeric (CN) and character numeric signed (CS) data types. 
Alternatively, a capability to define "edit masks" to insert literal information 
into subfields of character fields could be provided. 

We have no plans to provide these enhancements at this time, although 
sufficient user demand could generate some. 



OPERATING SYSTEMS Q&A - PG. 2 



Sufondtted by Alexander Gelbiean, Coulter Electronics, Hlaleah, FL: 

How long will you continue to expand and enhance DXIO? 

TI Answer: We will continue to support DXIO as long as customers continue to 
enthusiastically purchase 990 systems. Since DXIO is a very mature product, it 
is difficult to make major expansions or enhancements without changing the 
internal design. The DNOS operating system was implemented to allow us to 
redesign the internals of our 990 operating system and make major enhancements 
without perturbing the extensive base of DXIO customers who like DXiO just the 
way it is. Each system provides some unique attributes and the customer must 
pick the one which best suits his needs. 



Subnitted by Robert J. Mateer, Los Angeles City Schools , Los Angeles, CA: 

Error messages are often misleading. Many hours spent chasing up wrong trees. 
What is being done to improve messages? 

TI Answer: You may write STRs against documentation as well as software. 
Document specific error messages which are misleading and submit an STR against 
that message. If you have suggestions as to how the message can be improved, be 
sure to include them. 



SulmLtted by Darrls (Silvers, Antonated Services, Salt Lake City, DT: 

Will we be able to, at sysgen, specify the size wanted for the synonym table 
area and keyword area? Could we have "TAGS" or "LABELS" within a proc so we 
could start at a certain place like on a restart, 

TI Answer: DNOS supports a much larger synonym area than DXIO. The fixed size 
synonym space is an integral part of the design of DXIO SCI and would be very 
difficult to change. A restart capability for batch streams has been considered 
before, and this too, would be a very extensive change to SCI which we currently 
do not plan to do. 



Subnitted by Doane A. Schley, Computer Sharing Corporation, Minneapolis, MN: 

Why doesn't the TPD DSR send X-on and X-off to the remote terminal when data is 
v,^.*^ y.yj^ o-cxou isji. uuc v^r u u u gts u xuf \ Lx. now cannoc gee it rast enougn.) 

TI Answer: The TPD DSR provides KSR support for a wide range of keyboard 
devices (743/5, 78X, 820). We have not experienced any problems with accepting 
data from the keyboard of such devices. The TPD DSR also provides ASR support 
for the 763/5 family. As such, it takes the necessary steps to accept data from 
the bubble memory. Without specific information about the system configuration 
and devices, we cannot determine the problem stated here. By sysgening a large 
enough character queue, we have been able to overcome any problems suppporting 
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TI devices. We will investigate what would be necessary to add general purpose 
X«on:/X=o ff support . 



Submitted by Vickie Staples, Prodata Computer Marketing, Seattle, WA: 

What is the maximum baud rate at any given time for remote terminals on an S372 
(e.g., 110 has 9600 max and 112 has 1920 max)? How soon before S300s are a 7 
terminal system? 

TI Answer: The intent of this question is not quite clear. The S300 using the 
Tl-provided DSRs can currently support three terminals, each of which is running 
at 9600 baud. The CI-422 four channel option board will be available in late 
2Q83 to provide an additional four ports, for a total of seven. The RS-232G 
ports on the S300 should not be clocked in excess of 9600 baud each. We have 
tested a seven terminal S300 configuration, and found no problems. We are 
currently pursuing tests of six terminals (at 9600) with 3780, and with 
3270/ ICS, Our intent is to identify and fix any problems which we may find in 
DXIO 3.6 User written DSRs may not follow the conventions as TI does, thus this 
answer does not apply to such environments. 



Submitted by L. Allan Butler, Associated Medical Devices, Inc., Denver, 00: 

Will AMPL be supported under DNOS? If so, when? 
TI Answer: AMPL will not be supported under DNOS. 

Submitted by Gordon Alley, Automatic Control Electronics Co., San Antonio, TX: 

Are there any DNOS/M systems running? Will networking systems support DNOS/M 
for booting, remote file access, etc.? 

TI Answer: There are no DNOS/M systems running, and DNOS/M will not be 
supported in the future. 

Submitted by Stephen D. Jungersen, Data Concepts, Inc., Morton Grove, IL: 

Are there any plans for a 32-bit and/or multiprocessing system in the works? 

TI Answer: We are planning an advanced architecture product which will have 
an addressing capability greater than 16 bits. We have no plans to develop 
close-coupled multiprocessing but continue to see Local Area Networks as the key 
to a distributed processing strategy. 
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Sulniitted by Santiago Monte jo, Hldroestudlos , Bogota, Columbia, S.A.: 

We have problems estimating CPU time. Is there any utility to help us solve 
this problem? 

TI Answer: The DNOS accounting file records exact CPU times used by tasks 
during execution. The SMM display on DXIO and the XPD display on DNOS give GPU 
utilization figures which can be used in stand-alone environments to compute 
actual CPU times. Come and see an appropriate member of the OS panel at TI-MIX 
to discuss your specific situation to see if other tools may be available. 



Subnitted by Wllllaii J. Callahan, Service Engineering, Inc., Dracnt, MA: 

Are there any plans to migrate UNIX to TI equipment? 

TI Answer: We have no plans to migrate UNIX to 990-based systems. We are 
aware of the pervasiveness of UNIX in the marketplace and will certainly 
evaluate the possibility of offering it on future products. 



Sttbnitted by Victor M. Looden, General Electric Supply Co., Bridgeport, ON: 

When will TI allow two (or more) processors to work together? 

TI Answer: See the above answer to Stephen Jungersen's question. 

In the following list of questions and comments for the Operating Systems 
Question and Answer session, any comment is to be taken to mean "can it be 
done, and when will it be scheduled for implementation?" All questions and 
comments pertain to DXIO . 

( * Questions are new ones; other questions are repeats, with possible 
rewording from previous discussions . The repeats are included to indicate that 
they are still applicable, and to get a status report on those which were to be 
included in future releases.) 

1. Positive Comments 

*1. Many of the items discussed at TI-MIX 1982 and in this session in 
particular, have found their way into future releases. This fact has 

rr nrt t^ imr«rtt--i/>ak»4 'iry A -to «£»*"f--3-ii-«1tT o t> t^ -••^^ /-« -i <-» t- .-k4 " Vm^-n ^-.-n ■•-1-.^ ^^^ J f.^%»1^ " 

(Maybe we can even do it faster). 
*2. The revised manuals for 3.5 show a great improvement. 

2. Regarding KIF files and record locking ; 

a. The delete operation should require that the record be locked by the 
task performing the delete, just as in a write operation. This 
would prevent two tasks from attempting to delete the same record. 
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b. Problems arise when two tasks attempt to insert records with the 
same key at the same time (after already determining that the record 
was not there). This could be avoided if there existed an op code to 
"read and insert if not found." 

c. How do you protect the currency in one task when another task deletes 
the record which is pointed to by the currency block of the first 
task? This should not be left for the user to worry about. 

d. How do you define keys which are made up of noncontiguous fields? It 
is wasteful of storage and just plain annoying to have to create dupli- 
cate fields just to construct the necessary keys. 

*e. Why is it necessary that the primary key always be non-modifiable when 
using sequential placement? Many times this is a real nuisance. 



TI Aasners: 



2a. This request is currently in our backlog of design requests. 
We can currently make no commitment as to when resources will be 
available to implement the changes required. 

2b. The desired result can be accomplished by defining the key 
as "no duplicates allowed" and then just using INSERT. If this 
is not a valid solution for your specific situation, see an 
appropriate member of the OS panel at TI-MIX in order to clarify 
the exact problem. 

2c. This is in our backlog of design requests, but it is a very 
difficult problem to fix. "Rie currency information would have to 
be maintained in system space instead of task space. All tasks 
which maintain their own currency would be adversely affected. 

2d. Our original KIF requirements have their roots in support of 
ANSI standard COBOL. COBOL only allows one data field for a key 
definition which precludes accessing a key of non-contiguous 
fields. We currently have no plans to modify KIF to add this 
feature since it would be a major change to the KIF internal 
logic, 

2e. The COBOL ANSI standard asserts that the primary key on an 
indexed file will be non-modifiable. 



3. Regarding task edit keys and text editing; 

a. It is often desirable to duplicate the following line as well as the 
preceeding line (in a proc or in a text edit). Control 1 could be 
used for this. 

b. A Dup function which dups one character at a time would be very useful. 
This could be used with the repeat key to dup only the desired part of 
the line. (Control 2). 

c. The other function which is needed is to position the cursor at the end 
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of the current line (last nonblank plus 1). This could be done with 
Control 4, 

*d. Find string, replace string, and delete string should (*optionally) use 
line numbers (starting and ending), (*) in addition to the number of 
occurences, to control its range of application, 

*e. Replace string (* or maybe a new command called add string) should have 
the ability to insert a string at a specified position in the line. 

*f . A new function is needed that can "grab" a part of a line, and put it 
somewhere else. 



TI Answers: 



3a, This request is currently entered in our design backlog and 
will be considered as funding and resources permit, 

3b. This request is currently entered in our design backlog and 
will be considered as funding and resources permit, 

3c. This request is currently entered in our design backlog and 
will be considered as funding and resources permit. 

3d. This request is currently entered in our design backlog. If 
TAB settings are set appropriately the user should be able to tab 
very close to the desired position with very few keystrokes. 

3e. This is feature which is usually found in block-oriented 
editors as opposed to a line oriented editor such as the one we 
support. It would require a significant amount of change to the 
existing editor to provide this feature, 

3f, See 3e, 



4, Regarding the SCI: 

a. The ability to access two proc libraries was an invaluable enhancement, 
but two is not enough. We need at least three, and probably four. 
(Three allows the following breakdown: application, installation, 
system). 

b. The protection of primitives (via .OPTION) was also a valuable enhance- 
ment. This needs to be complemented by an option which restricts the 
direct user execution of procs to the first proc library, thus preven- 

a ^^*>_*.w xio^s vj. biiv^oc: J.LI uiic accuiiu ^,aaa tnxra ana rourun) iiora— 

ries. Under this option, proc in the second (and greater) libraries 
would be accessible only from procs in the first library. 

c. In general, there are two attributes for any output file which should 
be incorporated into all appropriate procs. These are "file status" 
and "open mode". "File status" has these values: BLANK = don't care 
or unknown, OLD = file must already exist, and NEW = file must not 
already exist. Note that REPLACE = NO means NEW, but there is no way 
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to specify OLD. "Open mode" has these values: OPEN, OPEN REWIND, AND 
OPEN EXTEND, For consistency, all procs which generate output should 
allow these options. This includes SVL, XB, LD, SVS, etc., just to 
name a few. 

*d. The proc language should allow "else if" as a control structure, 

*e. The proc language should allow logical operators (and, or, not) in ex- 
pressions on if (and else if) statements. 

*f • A task should be able to send a message to a station, similar to the CM 
command? (*) 

*g. When an error occurs in a proc (while testing a new proc), it is diffi- 
cult to know where you are, what parameter is missing, etc. Better 
diagnostics are needed. 

h. An HBT command to halt the background task would be useful. 

*i. Keyword table overflow is a frequent problem. Can the table be made 
any larger? 

*j. A proc can cause an overflow of the TCA parameter table without genera- 
ting an error. Can that be checked and an error produced? 

*k. SVC service errors (that really are not errors, e.g. file not found by 
delete operation) can be annoying to an end user. Could something be 
done to optionally turn off the display of such error messages. 

*1. It is often the case that you wish to return to the proc library(s) and 
menu from which you came (via .USE and .OPTION), but you have no way of 
knowing that state in all cases. The best solution would be for 
SCI to automatically stack (and allow the user to unstack) these 
states. Alternately, (but not a£ desirable), would be a mechanism to 
set a synonym with value equal to the current proc and menu state. 



TI Ansiiers: 



4a. DXIO 3.6 and DNOS 1.2 will both allow a maximum of 5 PROC 
libraries. 

4b. With DNOS File Security it will be possible to secure 
certain procedures to specific access groups. We currently do 
not have any plans to add the specific feature you request to 
DXIO or DNOS SCI since it would require major internal changes. 

4c. The (EXTEND, ADD, REPLACE) options are a part of SVL. We will 
evaluate other commands of this type as resources permit, 

4d. We agree but currently do not have resources to implement 
this feature. This is in our design backlog. 

4e. We agree but currently do not have resources to implement 
this feature. This is in our design backlog. 



OPERATING SYSTEMS Q&A - PG. 8 



4f . In DNOS it is possible to send a message to the "operator" 
from a task but we have no plans to implement a general message 
capability from tasks. 

4g. In DNOS SCI the line number in which an error occurs is 
given as part of the error message, 

4h. -niis can be accomplished with an STS command and the HT 
command . 

4i. In DXIO the synonym table cannot easily be made any larger 
and we currently have no plans to make changes in this area. In 
DNOS the table is 12288 bytes long compared to 864 for DXIO, 

4j, We need to know the specific instance of overflow you are 
referring to. Either see a member of the OS panel at TI-MIX 
or submit an STR exactly describing the situation. 

4k. This is not easily done on DXIO since each processor task 
for the separate commands controls the displaying of the errors. 
We will enter this as a design request and investigate a more 
general solution to the problem, 

41. This would be another major change to SCI and we currently 
have no plans to implement this feature. On DNOS 1.2 the current 
set of PROG libraries is stored in a well known synonym ($$CL) 
and thus the user can save and restore the procedure libraries 
using the .SYN primitive. 



5. Directory and Volume Utilities 

a. Either LD or MD (short form) should include the record length as part 
of the listing. *^ 

b. l^ needs the following changes /addit ions : "Top Level Only" should' be 

Number of Levels"; "Directory Nodes Only" should be "List Types" with 
values S,R,K,D,P,I,A. These are obviously file types, i.e. D = Direc- 
tory nodes only, and A = All. 

c. The control files for CD, BD, etc. would be much more useful if the 
names in an INCLUDE or EXCLUDE statement could be a pattern (as well as 

a specific name). Thus EXCLUDE S$ would mean that all names 

beginning with S$ were to be excluded, and INCLUDE TEST would mean 
that all names ending with TEST were to be includedT~'(*) Range values 
would also be useful, i.e. INCLUDE A :M means all files with 

names that be^ln wit-h a f-v> »-/-«,,« v. m /u j_ rrr~" — ~~ , , - 

- - __„ — _ ^.^^^y^Q^.. ii, y^auw uu you copy nair or a direc- 
tory to another directory? Also, it would be useful if DD and MD 
allowed the use of control files. 

*d. Why does CD not convert physical record lengths for KIF files? 

*e. Is it intended that VC terminates on the first >0011 error rather than 
indicating the error and continuing with the next file? 
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*f . It is confusing as to how MVI uses a control file, and how the synonym 
"$$DSC$" gets set. Also, it would be useful if another disk could be 
specified within MVI without having to Quit and then invoke it again. 

*g. Scan Disk (SD) will allow its output to be sent to a device, (only a 

file), and it opens the file with exclusive access making it impossible 
to view while the task is executing. Also, what will auto-correct do 
(and not do)? 



TI Answers : 



5A. The MD command of a given file can be used to obtain the 
logical record length of that file. Our experience has shown 
that if we change the output of a particular utility we break 
utilities written to accept that file as input and are requested 
to put it back the way it was. For instance, the May issue 
of MIX-TIPS will contain a number of instances requiring MD 
output to remain constant. 

5b. "Riis is in our current design request backlog and will be 
considered as time and resources permit. 

5c. We currently have no plans to implement this feature in our 
backup utilities. The utilities were not designed with these 
features in mind and adding these features would force us to 
essentially rewrite major portions of the logic. 

5d. Hie internal structures of KIF files are based on physical 
record length. The directory utilities do not understand the 
internal structures of KIF files and make no attempt to do 
physical record level conversion. The CKR utility may be used to 
copy one KIF file into another pre-created KIF file with a 
different physical record length, 

5e. VC should continue after errors rather than stopping on the 
first error. Have you submitted an STR on this problem? We will 
investigate it. 

5f . MVI uses a control file as if it is reading from a TTY 
device interactively. Each input must be on a separate line of 
the file. We do not understand the context of your question 
concerning the synonym $$DSC$. Please see an appropriate member 
of the OS panel and ask your question to them. We will enter 
your request to change the disk name dynamically into the design 
data base and consider it for future releases. 

5g. SD has been updated in DXIO 3.6 and DNOS 1.2. It will run 
in foreground and has the option of displaying its search 
progression as it runs. The SD utility is written in FORTRAN 
which opens input and output files with exclusive use which 
precludes looking at a file from another station. The new code 
will allow output to a device on both DXIO and DNOS. 
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6. Tasks and Lunos 

a. In CPI, it is desirable to replace a task by name without having to 
know its installed ID. 

b. If procedures could be made station local (optionally), then a family 
of cooperating tasks could share data through a dirty procedure. This 
is impossible now since all procedures are global • 

c. XT needs the option DISP = NO, as in AL and AGL. 

*d. The station number should be a parameter (with default "me") when 

assigning a station local luno. "niis is needed when a task is initia- 
ted at one station but is associated with another. The release opera- 
tion should be handled similarly, including RAL. 

*e. How can a task spawn another task and continue execution, and at some 
point, suspend itself pending completion of the spawned task? What is 
needed is a suspend SVC which is conditional on the completion of a 
specified task, i.e. the parent task should be able to place itself in 
a state >17 pending completion of the specified task. 

*f. Why can't a task or station local luno be associated with phantom sta- 
tion, i.e. a station which was not specified in the sysgen? Giving an 
error for the sake of giving an error is not to be considered just 
cause. 

*g. It would be very useful to have a new "kill task" command (or option on 
the current one), that "kills" all tasks associated with the specified 
station. 



TI Answers: 



6a. We agree this is a desirable feature and will attempt to 
implement it if funding and resources are available. This is 
already in our design request backlog. 

6b. This is in our design request backlog. It is possible to 
communicate with all tasks associated with a particular station 
if the station ID is stored as part of the message in the dirty 
procedure. 

6c. This problem will be fixed on DNOS 1.2 since it is merely a 
change to the proc but will not be fixed in DXIO 3.6 since 
development is source frozen already. 

V/-U. . J~i. a. (.CI.OCV j-a ci.oovyv.Juci<-cu wj.uxi. tx gj. v d.i ouoii.^\Jii ^c:vcLi jlx j. u j.o 

bid from a different one) and issues a station local Assign Luno 
SVC, the luno will be associated with the station the task is 
currently associated with. That is, if the "station local" bits 
are set in the SVC call block the feature should already exist as 
you have requested. If this is not true see an appropriate 
member of the OS panel at TI-MIX and let's discuss the 
exact situation. 
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6e, This feature as described would require some major changes 
in the PXIO kernel J and we currently do not anticipate making 
this change. The feature you desire can be accomplished by 
recording the ID of the spawned task after doing a normal bid 
task then periodically doing Poll Task Status calls on that task 
until it is determined that the spawned task has terminated. 
Incidentally, the DNOS semaphore mechanism provides this feature 
if you are interested. 

6f . Most users want to know if a LUNO has been assigned to a 
non-existent device. Errors are given because it is assumed if 
the user is assigning a LUNO to a device he expects the device to 
be there not "just to give an error for the sake of giving an 
error." Hie system has no way of determining whether a 
user expected that device to actually exist or not. The only 
devices known to the system are those included during a SYSGEN. 

6g. This is not a feature we have a great number of requests for 
but will consider it. The DNOS job structure provides a Kill Job 
command which kills all tasks under that job. 



7. Print Utilities 

*a. The "page eject" if PF and GC should be a parameter for both before 
and after printing, so that each user can tailor it to suit his needs 

b, PF should also have parameter to allow a halt between pages, (*) as 
well as a restart at specified line or page capability. 

TI Ansiiers: 

7a. The current method we have chosen for page ejects 
protects the unsophisticated user from printing on the last page 
of a previously printed file as well as handling embedded ANSI 
carriage control correctly. We will consider this feature as 
time and resources permit, and it is currently in our 
design backlog. 

7b. This capability exists in the DNOS spooler but we currently 
have no plans to incorporate this feature into DXIO PF. 



8. Link Editor 

a. The link edit control file should allow a copy command to include fre- 
quently used command sequences, or for example, the INCLUDES for a 
shared procedure. It should also allow a substitute command to sub- 
stitute one external reference name for another, 

TI Answer: A COPY command is an idea we have considered in the past, but have 
not had the resources to do as of yet. We will continue to considei 
this capability. We would like to know more about the SUBSTITUTE 
command since we have not had many requests for such a feature. 
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*9. Connnuiii cat ions 

*a. The TPD DSR has capabilities that are not directly user accessible, 
e.g. parity options, the end -of -record character, etc. These options 
should be settable in the system, and modifiable by MHPC or equivalent. 
Additionally, some option should be provided such that the DSR does not 
attempt to interpret any characters received, such as a DC3 (>13) . 
This could be done using a special terminal type, or by specifying no 
terminal type , 

TI Answer: It appears that some people are trying to utilize the TPD DSR 
(teleprinter DSR) for third-party devices and "home-brew" 
protocols. While this is possible in many cases, the list 
of exceptions would quickly get larger than the rules if we 
tried to add every feature necessary for a completely general 
purpose DSR. We are making some changes for DXIO 3.6 in the 
area of 8-bit data support that may address Fred's desire for 
not interpreting certain characters. We may be able to better 
document some of the facilities that are present to make them 
"user accessible", and will investigate doing this. 



*10. Sysgen 

*a. Prior to release 3.5, sysgen showed the current values of device para- 
meters when in change mode for that device, and used those values as 
defaults. That was a useful feature which seems to have disappeared, 

TI Answer: The XGEN utility was totally rewritten in Pascal between 3.4 and 
3.5. Even though the default feature disappeared, the user was 
given the ability to show, print, and text edit (with care) the 
configuration file which we feel offsets the lack of displaying 
defaults in "change" mode. We will investigate what it would 
take to add that feature back. 



*11. Miscellaneous 

*a. We always seem to have a significant increase in system crashes (>20, 
>27, >A0) following a new OS release. This slowly returns to normal 
after several patch updates. Why does this happen? 

TI Answers: We spend a great deal of time testing our newly released 

software, but the number of hardware configurations, software 
packages, and timing problems to be handled by an operating 
system are enormous. We cannot create every possible configur- 
ation and test every software package against it. We do test 
thoroughly against representative configurations, but many 
times problems are not found until a particular situation is 
created by a customer. As these problems are reported, they 
are patched in a patch release, and the system becomes more 
stable over time. 
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